`````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/29

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

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


Hoofdstuk 1. 

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.)


[2] De termen zijn synoniem, zoals vermeld in het Voorwoord/Preface. Zie de sectie genaamd “"Free" Versus "Open Source"” voor meer.

[3] Natuurlijk, het is nog steeds een goed idee voor hen dat ze af en toe ook echte conferenties bijwonen; zie de sectie met de naam:  “Meeting In Person (Conferences, Hackfests, Code-a-Thons, Code Sprints, Retreats)”.




Verder
Geschiedenis



/producingoss/ ✏️WIKI






Dit is een nieuwe webpagina

Bijgewerkt door — Priscilla F. Harmanus


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

 




 

 

 

 

 
Map
Info