`````Cybercrime en Cyber Security Nederland
PRISCILLA F. HARMANUS OVER ONDERZOEK INFORMATIE VEILIGHEID EN VITALE INFRASTRUCTUUR IN DE DIGITALE OVERHEID

Home » Digitale overheid » Actueel » Onderwerpen » Bijdrage » Contact

2021/01/27

Producing Open Source Software

Alle hyperlinks die naar een andere website leiden, hebben deze mooie groene kleur: voorbeeld link

/producingoss/ ✏️WIKI

Introductie » Geschiedenis » De Opkomst van Propriëtaire Software en Vrije Software » Bewust Verzet » Onopzettelijk Verzet » "Free" Versus "Open Source" » De Situatie Vandaag

Onderstaande tekst is vertaald vanuit het Engels (bron producingoss.com) naar het Nederlands door Priscilla Harmanus


Hoofdstuk 1. Introductie

Vrije software — open source software [2] — is de ruggengraat van de moderne informatietechnologie geworden. Het werkt op je telefoon, op je laptop en desktop computers, en in ingebouwde microcontrollers voor huishoudelijke apparaten, auto's, industriële machines en talloze andere apparaten waarvan we maar al te vaak vergeten dat ze zelfs software hebben. Open source komt vooral voor op de servers die online services op internet aanbieden. Elke keer dat u een e-mail verstuurt, een website bezoekt of informatie op uw smartphone oproept, wordt een aanzienlijk deel van de activiteit afgehandeld door open source software.

Toch is het ook grotendeels onzichtbaar, zelfs voor veel mensen die in de technologie werken. De aard van open source is om naar de achtergrond te verdwijnen en onopgemerkt te blijven, behalve door degenen wier werk het rechtstreeks raakt. Het is het plankton van computers. We ademen allemaal, maar weinigen van ons staan stil bij de vraag waar de zuurstof (oxygen) vandaan komt.

Als je tot nu toe hebt gelezen, ben je al een van de mensen die zich afvraagt waar de zuurstof vandaan komt, en waarschijnlijk wil je er zelf een maken.

Dit boek onderzoekt niet alleen hoe u open source goed kunt doen, maar ook hoe u het verkeerd kunt doen, zodat u problemen vroegtijdig kunt herkennen en corrigeren. Ik hoop dat je na het lezen een repertoire van technieken zult hebben, niet alleen om veelvoorkomende valkuilen te vermijden, maar ook om de groei en het onderhoud van een succesvol project aan te pakken. Succes is geen nulsomspel, en dit boek gaat niet over winnen of de concurrentie voor zijn. Een belangrijk onderdeel van het runnen van een open source-project is inderdaad het soepel werken met andere, gerelateerde projecten. Op de lange termijn draagt elk succesvol project bij aan het welzijn van de algehele, wereldwijde hoeveelheid vrije software (free as in freedom).

Het zou verleidelijk zijn om te zeggen dat wanneer vrije softwareprojecten mislukken, ze dat doen om dezelfde redenen als propriëtaire softwareprojecten. Vrije software heeft zeker geen monopolie op onrealistische vereisten, vage specificaties, slecht personeelsbeheer, het negeren van gebruikersfeedback of een van de andere hobgoblins die al goed bekend zijn in de software-industrie. Er is enorm veel geschreven over deze onderwerpen, en ik zal proberen het niet in dit boek te herhalen. In plaats daarvan zal ik proberen de problemen te beschrijven die eigen zijn aan vrije software. Wanneer een vrij softwareproject (free software project) vastloopt, komt dat vaak doordat de deelnemers de unieke problemen van open source softwareontwikkeling niet waardeerden, ook al zijn ze misschien redelijk goed voorbereid op de bekendere problemen van closed-source ontwikkeling of closed-source development.

Een van de meest voorkomende fouten zijn onrealistische verwachtingen over de voordelen van open source zelf. Een open licentie garandeert niet dat hordes actieve ontwikkelaars plotseling hun tijd aan uw project zullen besteden, en evenmin geneest open-sourcing van een onrustig project automatisch de problemen ervan. In feite is het tegenovergestelde: het openen van een project kan hele nieuwe complexiteiten toevoegen en op korte termijn meer kosten dan het simpelweg intern houden (keeping it in-house).

Opening up betekent dat de code begrijpelijk is voor vreemden/complete strangers, het schrijven van ontwikkelingsdocumentatie/development documentation en de opzet van discussieforums en andere samenwerkingshulpmiddelen/collaboration tools (dit wordt in meer detail besproken in Hoofdstuk 3, Technische Infrastructuur).

Dit alles is werk, en is in eerste instantie pure overhead. Als er geïnteresseerde ontwikkelaars komen opdagen, is er de extra last om hun vragen een tijdje te beantwoorden voordat ze enig voordeel van hun aanwezigheid zien. Zoals ontwikkelaar Jamie Zawinski zei over de moeilijke begindagen van het Mozilla-project:


Open source werkt wel, maar is zeker geen wondermiddel. Als er hier een waarschuwend verhaal is (a cautionary tale), is het dat je een uitstervend project (a dying project) niet kunt nemen, het kunt besprenkelen met het magische pixie stof van "open source", en alles magisch heeft laten werken. Software is moeilijk. De problemen zijn niet zo eenvoudig.

(van https://www.jwz.org/gruntle/nomo.html)


Een verwante fout is dat men beknibbelt op presentatie en verpakking, in de veronderstelling dat dit altijd later kan, als het project in volle gang is. Presentatie en verpakking omvatten een breed scala aan taken, allemaal rond het thema van het wegnemen van afleidingen en cognitieve barrières voor nieuwkomers - het verminderen van de hoeveelheid werk die ze moeten doen om van waar ze ook zijn naar "de volgende stap" van betrokkenheid. De website moet er goed uitzien, de compilatie, verpakking en installatie van de software moet zo veel mogelijk geautomatiseerd zijn, enz.

Veel programmeurs beschouwen dit soort werk helaas als ondergeschikt aan de code zelf. Hier zijn een aantal redenen voor. Ten eerste kan het aanvoelen als busywork, omdat de voordelen ervan het meest zichtbaar zijn voor degenen die het minst bekend zijn met het project — en vice versa: de mensen die de code ontwikkelen, hebben de verpakking immers niet echt nodig. Ze weten al hoe ze de software moeten installeren, beheren en gebruiken, want ze hebben het geschreven. Ten tweede zijn de vaardigheden die nodig zijn om goed te presenteren en in te pakken vaak totaal anders dan die vereist om code te schrijven. Mensen hebben de neiging zich te concentreren op datgene waar ze goed in zijn, ook al is het misschien beter voor het project om wat tijd te besteden aan iets dat minder bij hen past. Hoofdstuk 2, Aan De Slag gaat in detail in op presentatie en verpakking, en legt uit waarom het van cruciaal belang is dat ze vanaf het allereerste begin van het project prioriteit krijgen.

Vervolgens komt de misvatting dat er weinig of geen projectmanagement nodig is in open source, of omgekeerd, dat dezelfde managementpraktijken die worden gebruikt voor interne ontwikkeling even goed zullen werken bij een open source project.

Beheer of management in een open source project is niet altijd even zichtbaar, maar in de succesvolle projecten gebeurt het meestal achter de schermen in een of andere vorm. Een klein gedachte experiment is voldoende om te laten zien waarom. Een open source project bestaat uit een willekeurige verzameling programmeurs — al een notoir onafhankelijk ingestelde soort — die elkaar hoogstwaarschijnlijk nog nooit hebben ontmoet en die elk verschillende persoonlijke doelen hebben bij het werken aan het project. Het gedachte-experiment is simpelweg je voor te stellen wat er zou gebeuren met zo'n groep zonder management. Wonderen behouden, zou het heel snel instorten of uit elkaar drijven. Dingen lopen niet zomaar vanzelf, zoals we anders misschien zouden willen. Maar het management, hoewel het misschien behoorlijk actief is, is vaak informeel, subtiel en ingehouden. Het enige dat een ontwikkelingsgroep bij elkaar houdt, is hun gedeelde overtuiging dat ze meer samen kunnen dan individueel. Het doel van het management is dus vooral om ervoor te zorgen dat ze dit blijven geloven, door normen of standaarden vast te stellen voor communicatie, door ervoor te zorgen dat nuttige ontwikkelaars of developers niet worden gemarginaliseerd vanwege persoonlijke eigenaardigheden, En in het algemeen, door van het project een plek te maken, willen ontwikkelaars blijven terugkomen. Specifieke technieken om dit te doen worden in de rest van dit boek besproken.

Ten slotte is er een algemene categorie van problemen die "mislukkingen van culturele navigatie/failures of cultural navigation" kunnen worden genoemd. Twintig jaar geleden, zelfs tien jaar geleden, zou het voorbarig zijn geweest om te praten over een wereldwijde cultuur van vrije software, maar nu niet meer. Langzaam is er een herkenbare cultuur ontstaan, en hoewel het zeker niet monolithisch is — is het minstens zo vatbaar voor interne afwijkende meningen en factionalisme als elke andere geografisch gebonden cultuur — heeft het een in wezen consistente kern. De meeste succesvolle open source projecten vertonen enkele of alle kenmerken of eigenschappen van deze kern (core). Ze belonen bepaalde soorten gedrag en straffen anderen; ze creëren een sfeer die ongeplande deelname aanmoedigt, soms ten koste van centrale coördinatie; ze hebben concepten van onbeschoftheid en beleefdheid die aanzienlijk kunnen verschillen van die welke elders voorkomen. Het belangrijkste is dat deelnemers die al lang meedoen deze normen/standaarden over het algemeen hebben geïnternaliseerd, zodat ze een ruwe consensus delen over het verwachte gedrag (expected conduct). Mislukte projecten wijken meestal op significante manieren af ​​van deze kern/core, zij het onbedoeld, en hebben vaak geen consensus over wat redelijk standaardgedrag is (default behavior). Dit betekent dat wanneer zich problemen voordoen, de situatie snel kan verslechteren, aangezien de deelnemers niet beschikken over een reeds gevestigde voorraad culturele reflexen om op terug te vallen om verschillen op te lossen.

Die laatste categorie, mislukkingen van culturele navigatie, omvat een interessant fenomeen: bepaalde typen organisaties zijn structureel minder compatibel met open source-ontwikkeling of open source development dan andere. Een van de grote verrassingen voor mij bij het voorbereiden van de tweede editie van dit boek was het besef dat de ervaring over het geheel genomen aangeeft dat overheden minder geschikt zijn om deel te nemen aan vrije softwareprojecten dan bedrijven met winstoogmerk, met non-profitorganisaties ergens tussen de twee in. Hiervoor zijn veel redenen (zie de paragraaf/sectie met de naam “Overheden en Open Source”), en de problemen zijn zeker te overkomen, maar het is vermeldenswaard dat wanneer een bestaande organisatie — met name een hiërarchische, en vooral een hiërarchische, risicoaversie, en publiciteitsgevoelige — start of sluit zich aan bij een open source-project, de organisatie zal meestal enkele aanpassingen moeten doen.

De extra inspanning die nodig is om open source te draaien in plaats van gesloten is niet groot, maar de inspanning is het meest merkbaar vanaf het begin. Wat in het begin minder opvalt, zijn de voordelen, die aanzienlijk zijn en duidelijker worden naarmate het project vordert. Er is natuurlijk de diepe persoonlijke voldoening die het ontwikkelaars geeft: het plezier om je werk in het openbaar te doen, in staat om te waarderen en gewaardeerd te worden door je collega's. Het is geen toeval dat veel open source-ontwikkelaars of open source developers actief blijven op dezelfde projecten - als onderdeel van hun baan - zelfs nadat ze van werkgever zijn veranderd. Maar er zijn ook aanzienlijke organisatorische voordelen: de open source-projecten waaraan uw organisatie deelneemt, zijn een membraan waardoor uw managers en ontwikkelaars regelmatig worden blootgesteld aan mensen en ideeën buiten uw organisatiehiërarchie. Het is alsof u de voordelen heeft van het bijwonen van een conferentie, maar terwijl u toch dagelijks werk gedaan krijgt en zonder reiskosten te maken. [3] In a successful open source project, these benefits, once they start arriving, greatly outweigh the costs.

Dit boek is een praktische gids, geen antropologische studie of geschiedenis. Een praktische kennis van de oorsprong van de huidige vrije softwarecultuur is echter een essentiële basis voor praktisch advies. Iemand die de cultuur begrijpt, kan heinde en verre reizen in de open source-wereld, veel lokale variaties in gewoonten en dialect tegenkomen, maar toch overal comfortabel en effectief kunnen deelnemen. Iemand die de cultuur daarentegen niet begrijpt, zal het proces van het organiseren van of deelnemen aan een project moeilijk en vol verrassingen vinden. Aangezien het aantal mensen dat vrije software ontwikkelt, blijft groeien, vallen er veel mensen in die laatste categorie — dit is grotendeels een cultuur van recente immigranten, en dat zal nog een tijdje zo blijven. Als u denkt dat u een van hen bent, biedt het volgende gedeelte achtergrondinformatie voor discussies die u later zult tegenkomen, zowel in dit boek als op internet. (Aan de andere kant, als je al een tijdje met open source werkt, weet je misschien al veel van de geschiedenis, dus sla gerust de volgende sectie over.)





Verder
Geschiedenis


Introductie » History » The Rise of Proprietary Software and Free Software » Conscious Resistance » Accidental Resistance » "Free" Versus "Open Source" » The Situation Today



Geschiedenis

Het delen van software bestaat al zo lang als de software zelf. In de begintijd van computers waren fabrikanten van mening dat concurrentievoordelen voornamelijk te behalen waren bij hardware-innovatie, en besteedden daarom niet veel aandacht aan software als bedrijfsmiddel. Veel van de klanten voor deze vroege machines waren wetenschappers of technici, die de software die bij de machine werd geleverd zelf konden aanpassen en uitbreiden. Klanten verdeelden hun patches soms niet alleen terug naar de fabrikant, maar ook naar andere eigenaren van vergelijkbare machines. De fabrikanten tolereerden dit vaak en moedigden dit zelfs aan: in hun ogen maakten verbeteringen aan de software, van welke bron dan ook, de hardware alleen maar aantrekkelijker voor andere potentiële klanten.

Hoewel deze vroege periode in veel opzichten leek op de huidige vrije softwarecultuur, verschilde deze op twee cruciale punten. Ten eerste was er nog weinig standaardisatie van hardware — het was een tijd van bloeiende innovatie in computerontwerp, maar de diversiteit aan computerarchitecturen betekende dat alles incompatibel was met al het andere. Software die voor de ene machine is geschreven, werkt over het algemeen niet op een andere; programmeurs hadden de neiging om expertise op te doen in een bepaalde architectuur of familie aan architecturen (terwijl ze tegenwoordig eerder expertise zouden opdoen in een programmeertaal of familie aan talen, ervan overtuigd dat hun expertise kan worden overgedragen op de computerhardware waarmee ze toevallig werken). Omdat iemands expertise meestal specifiek was voor één soort computer, had hun opgebouwde expertise het effect dat die specifieke architectuurcomputer aantrekkelijker werd voor hen en hun collega's. Het was daarom in het belang van de fabrikant dat machine-specifieke code en kennis zo breed mogelijk zouden worden verspreid.

Ten tweede was er geen wijdverbreid internet. Hoewel er minder wettelijke beperkingen waren op het delen dan er nu zijn, waren de technische beperkingen groter: de middelen om gegevens van plaats naar plaats te krijgen waren relatief onhandig en omslachtig. Er waren enkele kleine, lokale netwerken, goed voor het delen van informatie tussen werknemers van hetzelfde laboratorium of bedrijf. Maar er bleven barrières overwonnen als men met de wereld wilde delen. Deze belemmeringen zijn in veel gevallen overwonnen. Soms legden verschillende groepen onafhankelijk contact met elkaar, stuurden schijven/disks of banden/tapes via landpost, en soms deden de fabrikanten zelf dienst als centrale verrekenkamer voor patches. Het hielp ook dat veel van de vroege computerontwikkelaars aan universiteiten werkten, waar het publiceren van hun kennis werd verwacht. Maar de fysieke realiteit van datatransmissie betekende dat er altijd een impedantie was om te delen, een impedantie die evenredig was met de afstand (reëel of organisatorisch) die de software moest afleggen. Wijdverbreid, probleemloos delen, zoals we dat nu kennen, was niet mogelijk.


De opkomst van propriëtaire software en vrije software

Naarmate de industrie volwassener werd, deden zich verschillende onderling samenhangende veranderingen tegelijkertijd voor. De wilde diversiteit aan hardware designs of hardware-ontwerpen maakte geleidelijk plaats voor een paar duidelijke winnaars — winnaars door superieure technologie, superieure marketing, of een combinatie van beide. Tegelijkertijd, en niet geheel toevallig, betekende de ontwikkeling van zogenaamde "high-level" programmeertalen dat men een programma eenmaal in één taal kon schrijven, en het automatisch kon laten vertalen ("compileren") om op verschillende soorten computers te draaien. De implicaties hiervan gingen niet verloren voor de hardwarefabrikanten: een klant kon nu een grote inspanning op het gebied van software-engineering ondernemen zonder zichzelf noodzakelijkerwijs op te sluiten in een bepaalde computerarchitectuur. Toen dit werd gecombineerd met de geleidelijke verkleining van prestatieverschillen tussen verschillende computers, omdat de minder efficiënte ontwerpen werden verwijderd, kon een fabrikant (manufacture) die zijn hardware als zijn enige bezit beschouwde, uitkijken naar een toekomst met dalende winstmarges. Ruwe rekenkracht werd een vervangbaar goed, terwijl software de differentiator werd. Het verkopen van software, of het op zijn minst behandelen als een integraal onderdeel van de hardwareverkoop, begon een goede strategie te lijken.

Dit betekende dat fabrikanten de auteursrechten op hun code strenger moesten gaan handhaven. Als gebruikers eenvoudigweg code vrijelijk onder elkaar zouden blijven delen en wijzigen, zouden ze zelfstandig enkele van de verbeteringen die nu door de leverancier als "toegevoegde waarde" worden verkocht, opnieuw kunnen implementeren. Erger nog, gedeelde code kan in handen van concurrenten komen. De ironie is dat dit alles gebeurde rond de tijd dat internet van de grond kwam. Dus net toen echt onbelemmerd delen van software eindelijk technisch mogelijk werd, maakten veranderingen in de computerbusiness het economisch onwenselijk, althans vanuit het oogpunt van een enkel bedrijf. De leveranciers hielden zich vast en ontzegden gebruikers de toegang tot de code die hun machines aanstuurde, of drongen aan op geheimhoudingsovereenkomsten (non-disclosure agreements) die effectief delen onmogelijk maakten.


Bewust Verzet

Terwijl de wereld van onbeperkte code-uitwisseling langzaam vervaagde, kristalliseerde een tegenreactie zich in de geest van ten minste één programmeur. Richard Stallman werkte in de jaren 70 en begin jaren 80 in het Artificial Intelligence Lab van het Massachusetts Institute of Technology, tijdens wat een gouden eeuw bleek te zijn en een gouden locatie voor het delen van codes. Het AI Lab had een sterke "hacker-ethiek", [4] en mensen werden niet alleen aangemoedigd, maar verwachtten ook dat ze alle verbeteringen die ze aan het systeem hadden aangebracht, zouden delen. Zoals Stallman later schreef:


We noemden onze software geen "vrije software", omdat die term nog niet bestond; maar dat was het. Wanneer mensen van een andere universiteit of een bedrijf een programma wilden porten en gebruiken, dan lieten we dat graag verhuren. Als je iemand een onbekend en interessant programma hebt zien gebruiken, zou je altijd kunnen vragen om de broncode te zien, zodat je deze kunt lezen, wijzigen, of delen ervan kunt kannibaliseren om een nieuw programma te maken.

(van https://www.gnu.org/gnu/thegnuproject.html)


Deze Edenic community stortte kort na 1980 in rond Stallman, toen de veranderingen die in de rest van de industrie hadden plaatsgevonden eindelijk het AI Lab inhaalde. Een startend bedrijf huurde veel van de programmeurs van het Lab in om te werken aan een besturingssysteem (OS) dat vergelijkbaar was met waar ze in het Lab aan hadden gewerkt, maar nu onder een exclusieve licentie. Tegelijkertijd verwierf het AI Lab nieuwe apparatuur die werd geleverd met een eigen (propriëtaire) besturingssysteem (OS).

Stallman zag het grotere patroon in wat er gebeurde:


De moderne computers van die tijd, zoals de VAX of de 68020, hadden hun eigen besturingssystemen, maar geen van hen was vrije software: je moest zelfs een geheimhoudingsverklaring ondertekenen om een uitvoerbare kopie te krijgen.

Dit betekende dat de eerste stap bij het gebruik van een computer was om te beloven je buurman niet te helpen. Een samenwerkende gemeenschap of een samenwerkende community was verboden. De regel van de eigenaren (owners) van propriëtaire software was: "Als je met je buurman deelt, ben je een piraat. Als je wijzigingen wilt, smeek ons dan om ze aan te brengen."


Door een eigenaardigheid van persoonlijkheid, besloot hij de trend te weerstaan. In plaats van verder te werken in het inmiddels gedecimeerde AI Lab, of een baan aan te nemen door code te schrijven bij een van de nieuwe bedrijven, waar de resultaten van zijn werk in een doos zouden worden bewaard, nam hij ontslag bij het Lab en startte het GNU project. en de Free Software Foundation (FSF). Het doel van GNU[5] was om een ​​volledig vrij en open computerbesturingssysteem en applicatiesoftware te ontwikkelen, waarin gebruikers nooit zouden worden belet om te hacken of hun wijzigingen te delen. Hij was in wezen van plan om te recreëren wat was vernietigd in het AI Lab, maar op een wereldwijde schaal en zonder de kwetsbaarheden die de cultuur van het AI Lab vatbaar hadden gemaakt voor desintegratie.

Naast het werken aan het nieuwe besturingssysteem bedacht Stallman een copyrightlicentie waarvan de voorwaarden garandeerden dat zijn code voor altijd vrij zou zijn. De GNU General Public License (GPL) is een knap stukje juridisch judo: er staat dat de code zonder beperking mag worden gekopieerd en gewijzigd, en dat zowel kopieën als afgeleide werken (dwz gewijzigde versies) onder dezelfde licentie moeten worden verspreid als het origineel, zonder aanvullende beperkingen. In feite gebruikt het auteursrecht/copyright om een ​​effect te bereiken dat tegengesteld is aan dat van traditioneel auteursrecht of copyright: in plaats van de distributie van de software te beperken, belet het iedereen, zelfs de auteur, om de distributie te beperken. Voor Stallman was dit beter dan simpelweg zijn code in het publieke domein plaatsen. Als het in het publieke domein zou zijn, zou een bepaalde kopie ervan kunnen worden opgenomen in een eigen programma (zoals soms ook gebeurt met code onder permissieve open source copyrightlicenties [6]). Hoewel een dergelijke opname op geen enkele manier de voortdurende beschikbaarheid van de originele code zou verminderen, zou het betekend hebben dat de inspanningen van Stallman de vijand ten goede konden komen  propriëtaire software. De GPL kan worden gezien als een vorm van protectionisme voor vrije software, omdat het voorkomt dat niet-vrije software volledig profiteert van de GPLed code. De GPL en zijn relatie tot andere vrije softwarelicenties worden in detail besproken in Hoofdstuk 9, Juridische Zaken (Legal Matters): Licenties (Licenses), Auteursrechten (Copyrights), Handelsmerken (Trademarks) en Patenten (Patents).


Met de hulp van veel programmeurs, van wie sommigen de ideologie van Stallman deelden en sommigen gewoon veel vrije code beschikbaar wilden zien, begon het GNU project met het vrijgeven van vrije vervangingen voor veel van de meest kritieke componenten van een besturingssysteem. Vanwege de nu wijdverspreide standaardisatie in computerhardware en software, was het mogelijk om de GNU vervangingen te gebruiken op anders niet-vrije systemen, en veel mensen deden dat. De GNU teksteditor (Emacs) en de C compiler (GCC) waren bijzonder succesvol en kregen grote en loyale volgers, niet op ideologische gronden, maar gewoon op hun technische verdiensten. Rond 1990 had GNU het grootste deel van een vrij besturingssysteem geproduceerd, behalve de kernel — het deel dat de machine daadwerkelijk opstart en dat verantwoordelijk is voor het beheer van geheugen (memory), schijf (disk) en andere systeembronnen (system resources).

Helaas had het GNU project een kernel ontwerp of kernel design gekozen dat moeilijker te implementeren bleek te zijn dan verwacht. De daaropvolgende vertraging verhinderde de Free Software Foundation om de eerste release van een volledig vrij besturingssysteem uit te brengen. Het laatste stuk werd in plaats daarvan aangebracht door Linus Torvalds, een Finse Computer Science (Informatica) student die, met de hulp van ontwikkelaars/developers over de hele wereld, een vrije kernel compleet had met een meer conservatief ontwerp. Hij noemde het Linux, en toen het werd gecombineerd met de bestaande GNU programma's en andere vrije software (vooral het X Windows-systeem/the X Window System), was het resultaat een volledig vrij besturingssysteem. Voor de eerste keer kon u uw computer opstarten en aan het werk gaan zonder elk propriëtaire software te gebruiken. [7]

Veel van de software op dit nieuwe besturingssysteem (OS) is niet geproduceerd door het GNU project. In feite was GNU niet eens de enige groep die werkte aan het produceren van een vrij besturingssysteem (bijvoorbeeld de code die uiteindelijk NetBSD en FreeBSD werd, was tegen die tijd al in ontwikkeling). Het belang van de Free Software Foundation zat niet alleen in de code die ze schreven, maar ook in hun politieke retoriek. Door te praten over vrije software als doel in plaats van gemak, maakten ze het voor programmeurs moeilijk er geen politiek bewustzijn van te hebben. Zelfs degenen die het niet eens waren met de FSF, moesten de kwestie aangaan, al was het maar om een ander standpunt in te nemen. De effectiviteit van de FSF als propagandisten lag in het koppelen van hun code aan een boodschap, door middel van de GPL en andere teksten. Terwijl hun code zich wijd verspreidde, verspreidde die boodschap zich ook.


Onopzettelijk Verzet

Er waren echter veel andere dingen aan de hand in de ontluikende vrije software scene, en niet alle waren zo uitgesproken ideologisch als Stallmans GNU project. Een van de belangrijkste was de Berkeley Software Distribution (BSD), een geleidelijke herimplementatie van het Unix-besturingssysteem — which up until the late 1970's had been a (loosely) proprietary research project at AT&T — door programmeurs van de University of California bij Berkeley. De BSD groep deed geen openlijke politieke uitspraken over de noodzaak voor programmeurs om samen te werken en met elkaar te delen, maar ze oefenden het idee met flair en enthousiasme uit, door een massale en enorme gedistribueerde ontwikkelingsinspanning/development effort te coördineren waarin de Unix-commandoregelhulpprogramma's (Unix command-line utilities) en codebibliotheken (code libraries), en uiteindelijk de kernel van het besturingssysteem zelf (the operating system kernel itself), werden grotendeels opnieuw geschreven door vrijwilligers. Het BSD project werd een vroeg voorbeeld van niet-ideologische ontwikkeling van vrije software en diende ook als oefenterrein voor veel ontwikkelaars die actief zouden blijven in de open source wereld.


Een andere smeltkroes van coöperatieve ontwikkeling was het X Window System, een vrij, netwerktransparante grafische computeromgeving, ontwikkeld bij MIT in het midden van de jaren 80 in samenwerking met hardwareleveranciers die er een gemeenschappelijk belang bij hadden om hun klanten een venstersysteem te kunnen bieden. In plaats van tegen propriëtaire software te zijn, stond de X-licentie opzettelijk propriëtaire uitbreidingen toe bovenop de vrije kern — elk lid van het consortium wilde de kans krijgen om de standaard X-distributie te verbeteren en daardoor een concurrentievoordeel te behalen ten opzichte van de andere leden (members). X Windows[8] zelf was vrije software, maar vooral als een manier om het speelveld tussen concurrerende bedrijfsbelangen gelijk te maken en de standaardisatie te vergroten, niet uit een verlangen om de dominantie van propriëtaire software te beëindigen. Nog een ander voorbeeld, dat een paar jaar ouder was dan het GNU project, was TeX, Donald Knuths vrije zetsysteem (free typesetting system) van publicatiekwaliteit. Hij bracht het uit onder voorwaarden die iedereen toestonden de code aan te passen en te verspreiden, maar het resultaat niet "TeX" te noemen, tenzij het een zeer strikte reeks compatibiliteitstests doorstaan ​​heeft (dit is een voorbeeld van de "handelsmerkbeschermende" klasse van vrije licenties  meer besproken in Hoofdstuk 9, Juridische Zaken (Legal Matters): Licenties (Licenses), Auteursrechten (Copyrights), Handelsmerken (Trademarks) en Patenten (Patents). Knuth nam op de een of andere manier geen standpunt in over de kwestie van free-versus-propriëtaire software; hij had gewoon een beter zetsysteem (typesetting system) nodig om zijn echte doel te bereiken  een boek over computerprogrammering  en zag geen reden om zijn systeem niet aan de wereld vrij te geven als hij klaar was.

Zonder elk project en elke licentie op te sommen, is het veilig om te zeggen dat er tegen het einde van de jaren tachtig veel vrije software beschikbaar was onder een grote verscheidenheid aan licenties. De diversiteit aan licenties weerspiegelde een overeenkomstige diversiteit aan motivaties. Zelfs sommige programmeurs die voor de GNU GPL kozen, waren veel minder ideologisch gedreven dan het GNU project zelf. Hoewel ze graag aan vrije software werkten, beschouwden veel ontwikkelaars propriëtaire software niet als een sociaal kwaad. Er waren mensen die een morele impuls voelden om de wereld te ontdoen van 'software hamsteren' (Stallmans term voor niet-vrije software), maar anderen werden meer gemotiveerd door technische opwinding, of door het plezier om met gelijkgestemde medewerkers samen te werken, of zelfs door een eenvoudig menselijk verlangen naar glorie. Maar over het algemeen werkten deze ongelijksoortige motivaties niet op destructieve manieren samen. Dit kan zijn omdat software, in tegenstelling tot andere creatieve vormen zoals proza ​​of beeldende kunst, semi-objectieve tests moet doorstaan ​​om als succesvol te worden beschouwd: het moet draaien en redelijk vrij zijn van bugs. Dit geeft alle deelnemers aan een project een soort automatische gemeenschappelijke basis, een reden en een kader om samen te werken zonder zich al te veel zorgen te maken over kwalificaties of motivaties die verder gaan dan het technische.

Ontwikkelaars (Developers) hadden nog een reden om bij elkaar te blijven: het bleek dat de vrije softwarewereld code van zeer hoge kwaliteit produceerde. In sommige gevallen was het technisch aantoonbaar superieur aan het dichtstbijzijnde niet-vrije alternatief; in andere was het op zijn minst vergelijkbaar, en het kostte natuurlijk altijd minder om te verwerven. Hoewel slechts een paar mensen op strikt filosofische gronden gemotiveerd waren om vrije software te gebruiken, waren heel veel mensen er blij mee omdat het beter werkte. En van degenen die het gebruikten, was een percentage altijd bereid om hun tijd en vaardigheden te doneren om de software te helpen onderhouden en verbeteren.

Deze neiging om goede code te produceren was zeker niet universeel, maar kwam steeds vaker voor in vrije softwareprojecten over de hele wereld. Bedrijven die sterk afhankelijk waren van software, begonnen dit geleidelijk op te merken. Velen van hen ontdekten dat ze bij de dagelijkse gang van zaken al vrije software gebruikten en het simpelweg niet wisten (het hogere management is niet altijd op de hoogte van alles wat de IT-afdeling doet). Bedrijven begonnen een actievere en meer publieke rol te spelen in vrije softwareprojecten, door tijd en apparatuur bij te dragen en soms zelfs rechtstreeks de ontwikkeling van gratis programma's te financieren. Dergelijke investeringen zouden, in de beste scenario's, zichzelf vele malen kunnen terugbetalen. De sponsor betaalt slechts een klein aantal deskundige programmeurs om zich fulltime aan het project te wijden, maar plukt de vruchten van ieders bijdragen, inclusief het werk van programmeurs die worden betaald door andere bedrijven en van vrijwilligers die hun eigen ongelijksoortige motivaties hebben.


"Free" Versus "Open Source"

Naarmate het bedrijfsleven steeds meer aandacht schonk aan vrije software, werden programmeurs geconfronteerd met nieuwe presentatiekwesties. Een daarvan was het woord "free/gratis" zelf. Bij het eerste horen van de term "vrije software/free software" denken veel mensen ten onrechte dat het gewoon "kosteloze software" betekent. Het is waar dat alle vrije software kosteloos is,[9] maar niet alle zero-cost software is vrij zoals in "vrijheid" (free as in freedom) — dat wil zeggen de vrijheid om te delen en aan te passen voor elk doel. Tijdens de strijd om de browsers in de jaren negentig gaven zowel Netscape als Microsoft bijvoorbeeld hun concurrerende webbrowsers kosteloos weg, in een strijd om marktaandeel te winnen. Geen van beide browsers was vrij in de zin van "vrije software". Je kon de broncode niet krijgen, en zelfs als je dat wel zou kunnen, had je niet het recht om deze te wijzigen of opnieuw te verspreiden.[10] Het enige dat u kon doen, was een uitvoerbaar bestand downloaden en het uitvoeren. De browsers waren niet meer gratis/free/vrij dan software in krimpfolie die in een winkel werd gekocht; ze hadden alleen een lagere prijs.

Deze verwarring over het woord "free/gratis" is volledig te wijten aan een ongelukkige dubbelzinnigheid in de Engelse taal. De meeste andere talen onderscheiden lage prijzen van vrijheid (het onderscheid tussen gratis en libre is bijvoorbeeld direct duidelijk voor sprekers van Romaanse talen). Maar de positie van het Engels als de feitelijke brugtaal van internet betekent dat een probleem met het Engels tot op zekere hoogte een probleem is voor iedereen. Het misverstand rond het woord "free/gratis" was zo wijdverbreid dat vrije softwareprogrammeurs uiteindelijk een standaardformule ontwikkelden als reactie: "Het is vrij zoals in vrijheid - denk aan vrije meningsuiting, niet aan gratis bier." "It's free as in freedom — think free speech, not free beer." Toch is het vermoeiend om het steeds opnieuw uit te leggen. Veel programmeurs waren met enige rechtvaardiging van mening dat het dubbelzinnige woord "free/gratis" het begrip van deze software bij het publiek belemmerde.

Maar het probleem ging dieper dan dat. Het woord "free/gratis" had een onontkoombare morele connotatie: als vrijheid een doel op zich was, maakte het niet uit of vrije software toevallig ook beter was, of in bepaalde omstandigheden winstgevender voor bepaalde bedrijven. Dat waren louter prettige neveneffecten van een motief dat bij de wortel noch technisch, noch commercieel, maar moreel was. Bovendien dwong de "vrij als in vrijheid" — positie tot een flagrante inconsistentie voor bedrijven die bepaalde gratis programma's wilden ondersteunen in één aspect van hun bedrijf, maar doorgaan met het op de markt brengen van eigen software in andere.

Deze dilemma's kwamen naar een gemeenschap die al klaar was voor een identiteitscrisis. De programmeurs die in feite vrije software schrijven, hebben het nooit eens gehad over het algemene doel, indien aanwezig, van de vrije softwarebeweging. Zelfs te zeggen dat meningen van het ene uiterste naar het andere gaan, zou misleidend zijn, omdat het ten onrechte een lineair bereik zou impliceren waar er in plaats daarvan een multidimensionale verstrooiing is. Er kunnen echter twee brede categorieën van overtuigingen worden onderscheiden, als we bereid zijn om op dit moment subtiliteiten te negeren. De ene groep is van mening dat Stallman van mening is dat de vrijheid om te delen en te wijzigen het belangrijkste is, en dat je daarom, als je stopt met praten over vrijheid, de kern hebt weggelaten. Anderen zijn van mening dat de software zelf het belangrijkste argument in hun voordeel is, en vinden het niet prettig om te verkondigen dat propriëtaire software inherent slecht is. Sommige, maar niet alle, vrije softwareprogrammeurs zijn van mening dat de auteur (of werkgever, in het geval van betaald werk) het recht moet hebben om de voorwaarden voor distributie te controleren, en dat er geen moreel oordeel hoeft te worden gehecht aan de keuze van bepaalde voorwaarden. Anderen geloven dit niet.

Deze verschillen hoefden lange tijd niet zorgvuldig te worden onderzocht of gearticuleerd, maar het groeiende succes van vrije software/free software in de zakenwereld maakte het probleem onvermijdelijk. In 1998 werd de term open source gecreëerd als alternatief voor "free/gratis", door een coalitie van programmeurs die uiteindelijk het Open Source Initiative (OSI) werd.[11] De OSI vond niet alleen dat 'vrije software/free software' mogelijk verwarrend was, maar dat het woord 'free/gratis' slechts één symptoom was van een algemeen probleem: dat de beweging een marketingprogramma nodig had om het aan de bedrijfswereld te presenteren, en dat gepraat over moraal en de sociale voordelen van delen would never fly in corporate boardrooms. In hun eigen woorden destijds:

Het Open Source Initiative is een marketingprogramma voor free software. Het is een pitch voor ‘vrije software’ op solide pragmatische gronden in plaats van ideologische dreunen. De winnende substantie is niet veranderd, de verliezende houding en symboliek wel...

Bij de meeste techneuten gaat het niet om het concept van open source, maar om de naam. Waarom noem je het niet, zoals we traditioneel hebben, free software?

Een directe reden is dat de term "vrije software/free software/gratis software" gemakkelijk verkeerd wordt begrepen op manieren die tot conflicten leiden...

Maar de echte reden voor de heretikettering is een marketingreden. We proberen ons concept nu te pitchen voor de zakenwereld. We hebben een winnend product, maar onze positionering in het verleden was verschrikkelijk. De term "vrije software/free software" is verkeerd begrepen door zakenmensen, die de wens om te delen verwarren met anti-commercialisme, of erger nog, diefstal.

Mainstream-CEO's en CTO's van bedrijven zullen nooit "free software" kopen. Maar als we dezelfde traditie, dezelfde mensen en dezelfde vrije softwarelicenties nemen en het label veranderen in "open source" — dat, zullen ze kopen.

Sommige hackers vinden dit moeilijk te geloven, maar dat komt omdat het techneuten zijn die concreet en substantieel denken en niet begrijpen hoe belangrijk het imago is als je iets verkoopt.

In marketing is uiterlijk realiteit. De schijn dat we bereid zijn om van de barricades af te klimmen en samen te werken met de zakenwereld, telt evenzeer als de realiteit van ons gedrag, onze overtuigingen en onze software.

(van https://www.opensource.org/. Of beter gezegd, voorheen van die site  de OSI heeft sindsdien blijkbaar de pagina's verwijderd, hoewel ze nog steeds te zien zijn op https://web.archive.org/web /20021204155057/http://www.opensource.org/advocacy/faq.php en https://web.archive.org/web/20021204155022/http://www.opensource.org/advocacy/case_for_hackers.php#marketing [sic].)


De toppen van vele ijsbergen van controverse zijn zichtbaar in die tekst. Het verwijst naar "onze overtuigingen", maar vermijdt op een slimme manier precies te omschrijven wat die overtuigingen zijn. Voor sommigen is het misschien de overtuiging dat code die is ontwikkeld volgens een open proces, betere code zal zijn; voor anderen is het misschien de overtuiging that all information should be shared. Er is het gebruik van het woord "diefstal/theft" om (vermoedelijk) te verwijzen naar illegaal kopiëren — een gebruik waar velen bezwaar tegen hebben, omdat het geen diefstal is als de oorspronkelijke bezitter het item daarna nog heeft. Er is de verleidelijke aanwijzing dat de vrije softwarebeweging/free software movement ten onrechte zou worden beschuldigd van anticommercialisme, maar het laat de vraag of een dergelijke beschuldiging in feite enige grondslag heeft, zorgvuldig ononderzocht.

Dat wil niet zeggen dat de website van OSI inconsistent of misleidend is. Is het niet. Het is eerder een voorbeeld van wat de OSI beweert te hebben gemist in de vrije softwarebeweging (The Free Software Movement): goede marketing, waar "goed" betekent: "levensvatbaar in de zakenwereld." Het Open Source Initiative gaf veel mensen precies datgene waarnaar ze op zoek waren: een vocabulaire om over vrije software te praten als ontwikkelingsmethodologie en bedrijfsstrategie, in plaats van als een morele kruistocht.

De opkomst van het Open Source Initiative veranderde het landschap van vrije software. Het formaliseerde een tweedeling die lange tijd geen naam had gehad, en dwong daarmee de beweging te erkennen dat ze zowel interne als externe politiek had. Het effect van vandaag is dat beide partijen een gemeenschappelijke basis hebben moeten vinden, aangezien de meeste projecten zowel programmeurs uit beide kampen omvatten als deelnemers die niet in een duidelijke categorie passen. Dit betekent niet dat mensen nooit praten over morele motivaties — er wordt bijvoorbeeld wel eens gewag gemaakt van fouten in de traditionele 'hacker-ethiek'. Maar het komt zelden voor dat een free software / open source ontwikkelaar (developer) openlijk de fundamentele motivaties van anderen in een project in twijfel trekt. De bijdrage overtreft de bijdrager. Als iemand goede code schrijft, vraag je hem niet of hij dat om morele redenen doet, of omdat zijn werkgever ze heeft betaald, of omdat hij zijn cv aan het opbouwen is, of wat dan ook. Je beoordeelt de bijdrage op technische gronden, en reageert op technische gronden. Zelfs expliciet politieke organisaties zoals het Debian project, wiens doel het is om een ​​100% vrij (dat wil zeggen, "vrij als in vrijheid/free as in freedom") computeromgeving aan te bieden, zijn tamelijk ontspannen over de integratie met niet-vrije code en het samenwerken met programmeurs, die niet precies dezelfde doelen delen.


[2] The terms are synonymous, as mentioned in the Preface. See the section called “"Free" Versus "Open Source"” for more.


[3] Of course, it's still a good idea for them to attend real conferences once in a while too; see the section called “Meeting In Person (Conferences, Hackfests, Code-a-Thons, Code Sprints, Retreats)”.


[4] Stallman uses the word "hacker" in the sense of "someone who loves to program and enjoys being clever about it," not the somewhat newer meaning of "someone who breaks into computers."


[5] It stands for "GNU's Not Unix", and the "GNU" in that expansion stands for an infinitely long footnote.


[6] See the section called “Terminology” for more about "permissive" licensing versus GPL-style "copyleft" licensing. The opensource.org FAQ is also a good resource on this — see https://opensource.org/faq#copyleft.


[7] Technically, Linux was not the first. A free operating system for IBM-compatible computers, called 386BSD, had come out shortly before Linux. However, it was a lot harder to get 386BSD up and running. Linux made such a splash not only because it was free, but because it actually had a high chance of successfully booting your computer after you installed it.


[8] They prefer it to be called the "X Window System", but in practice, people usually call it "X Windows", because three words is just too cumbersome.


[9] One may charge a fee for giving out copies of free software, but since one cannot stop the recipients from offering it at no charge afterwards, the price is effectively driven to zero immediately.


[10] The source code to Netscape Navigator was eventually released under an open source license, in 1998, and became the foundation for the Mozilla web browser. See https://www.mozilla.org/.


[11] OSI's web home is https://www.opensource.org/.





Verder
De Situatie Vandaag


Bron


Zie ook


Hoort bij


Producing Open Source Software


Home » Digitale overheid » Actueel » Onderwerpen » Bijdrage » Contact

 
Map
Info