Ansel moet democratisch en eerlijk voor iedereen die erbij betrokken is worden bestuurd.

Een coöperatieve organisatie definiëren die verder gaat dan open-sourcecode

Van ontwikkelaars en gebruikers die hier terechtkomen wordt aangenomen dat ze een gemeenschappelijk belang delen: ze willen vrijheid in hoe ze hun foto’s bewerken, nu en in de toekomst. Wat betekent:

  • voldoende technische controle hebben over de inhoud en eigenschappen van hun beeld,
  • vrij zijn van kapitalisten die kunnen:
    • de prijs van hun applicatie verhogen uitsluitend ten gunste van de aandeelhouders,
    • de foto’s van klanten ontginnen om AI-modellen te trainen zonder toestemming,
    • applicaties opheffen zonder de broncode vrij te geven,
  • het recht hebben om te beslissen over de contouren en de invulling van die vrijheid.

Het DNA van Ansel is technischer en fijnmaziger dan de meeste raw-fotobewerkers, terwijl het waar mogelijk toch de nadruk legt op gebruiksvriendelijkheid, vooral bij typische desktop-gerichte taken (interacties met invoerapparaten en bestanden, GUI-paradigma’s, enz.). Ansel is niet Darktable  of ART , omdat zijn visie op wat een goede beeldretoucheersoftware zou moeten zijn nogal verschilt.

Ansel wordt uitgebracht onder de GNU/GPL-licentie , wat het tot vrije/open-sourcesoftware maakt. Hoewel dit een (verkeerd) gevoel van langdurige beschikbaarheid geeft, is de realiteit dat de langdurige beschikbaarheid ervan uitsluitend afhangt van de wil en het vermogen van een aantal ontwikkelaars om het (vervelende) dagelijkse onderhoud uit te voeren om het werkend te houden, nieuwe camera’s te blijven ondersteunen, enz., wat een onderschatte taak is omdat het geen spectaculaire release notes of keynotes oplevert.

Erger nog, de zogenaamde „vrijheid" die de GNU/GPL-licentie verleent, heeft alleen betrekking op de broncode: het is de vrijheid van de ingenieur. Open-sourcelicenties doen in wezen afstand van het intellectuele eigendom op de code, wat betekent dat ingenieurs die kunnen bestuderen en wijzigen, en vervolgens hun wijzigingen kunnen delen. Aangezien minder dan 6 % van de wereldbevolking1 daadwerkelijk code kan schrijven, is dit een recht voor slechts een bevoorrechte minderheid. En wat de gebruikers betreft, tja, de GPL-licentie is vrij duidelijk:

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY;

Deze verklaring sluit eindgebruikers in wezen uit van de transactie: ze hebben geen andere rechten dan de code as-is uit te voeren, en met name geen recht op ondersteuning en bugfixes, laat staan het recht om de software naar hun behoeften te laten vormen. Als er toch enige ondersteuning wordt geboden, dan is dat ter discretie van de ontwikkelaars en zouden gebruikers daar eeuwig dankbaar voor moeten zijn. Hiervan wordt in zogenaamde „open-sourcegemeenschappen" (lees: „softwareforums") misbruik gemaakt om elke klacht van gebruikers de kop in te drukken en ongeldig te verklaren: ze kunnen simpelweg niet klagen, aangezien ze gratis werk gebruiken, ook al bezingt de marketing van open-sourceprojecten vaak in lyrische bewoordingen de „professionele" geschiktheid van die applicaties. Maar… er werden beloftes gedaan, het woord „pro" werd uitgesproken maar niet waargemaakt, dus er zit ergens een misleidende inconsistentie.

Zelfs terwijl ze afstand doen van elke verantwoordelijkheid tegenover gebruikers, proberen veel projecten hen toch te veranderen, zo niet in klanten, dan toch op zijn minst in donateurs. Wat op een treurige stand van zaken stuit: 350 jaar kapitalisme heeft onze hersenen zo verrot dat we denken dat open-sourceapplicaties de goedkoopste concurrent van propriëtaire software zijn. Gebruikers blijven gewoon op hun luie krent zitten wachten tot de projecten een product afleveren, alvorens te beslissen of ze de moeite zullen nemen om te doneren. Dit is alsof je de NASA pas begint te financieren nadat de eerste raket is gelanceerd om te bewijzen dat het project inderdaad kan leveren: dat kan niet. Je moet het werk betalen nog voordat er een product te verkopen is. En wanneer het product wordt uitgebracht, hebben projecten als Wikipedia nog steeds moeite om minder dan 3 $/jaar van 2 % van hun gebruikersbasis te krijgen.

Open-sourceapplicaties zijn concurrenten van propriëtaire applicaties, net zoals openbare ziekenhuizen concurrenten zijn van privéklinieken: dat zijn ze niet. Aan de ene kant hebben we een socialistisch project dat is ontstaan vanuit de overtuiging dat iedereen recht heeft op gezondheidszorg, en als ze het zich niet kunnen veroorloven, redden we ons wel door extra geld te vinden binnen de gemeenschap. Aan de andere kant hebben we aandeelhouders die winst proberen te maken, chirurgen inhuren die proberen hun huis in Malibu en hun Porsche-collectie te betalen. Hoe zijn zij concurrenten? Een openbare dienst is een manier om ervoor te zorgen dat mensen de middelen hebben om hun rechten uit te oefenen, want vrijheid is slechts theoretisch totdat je de middelen hebt om daadwerkelijk gebruik te maken van je rechten. Een privébedrijf dat goederen of diensten verkoopt is een manier om geld te verdienen uit investeringen. Het verschil is politiek. Het is ook economisch, aangezien het niet hebben van de aandeelhouders op de loonlijst het eindproduct sowieso betaalbaarder maakt.

De blinde vlek van de „Free Software"-beweging was het vermijden van nadenken over de context en de werkstructuur waarin dergelijke software ontstaat, wordt ontwikkeld en onderhouden. Dit is terug te voeren op de hackercultuur , die van nature individualistisch is en bij volmacht kapitalisme-compatibel, via technofilie  en technosolutionisme . „Delen as-is" (je werk, je code, je hacks) werd verward met „zorgen voor" (de behoeften, beperkingen en uitdagingen van andere mensen) en onderhouden met quasi-hagiografische verhalen. Als je een hamer hebt, ziet alles eruit als een spijker: als het enige wat je kent code is, dan is code de oplossing voor alles, en het te proberen verpakken in filosofie en (niet-revolutionaire) politiek om „codevrijheid" te definiëren mist nog steeds het grote plaatje, namelijk de uitbuiting van ieders werk door een kleine maar machtige en zichzelf reproducerende sociale klasse. Terwijl 6 % van de wereldbevolking in 2021 code kon schrijven, was het aandeel dat zich überhaupt een personal computer kon veroorloven in de jaren 1980, toen de Free Software-beweging begon, veel kleiner. Bevoorrechte minderheden zijn altijd blind voor hun privileges: zo herken je ze. Ze zagen niet in dat Free software niets meer was dan het geesteskind van die privileges. Het is alleen vrijheid voor wie het zich kan veroorloven. En het feit dat er geen dollarteken aan het prijskaartje hangt, maakt het venijnig. Er hangt nog steeds een prijskaartje aan.

De Free Software-beweging was gemaakt om te passen in dit individualistische, vrije-ondernemings-, liberale-markt-kapitalisme, en liet iedereen denken dat het genoeg was om iedereen zijn eigen project te laten starten of het van anderen te laten forken. Vervolgens zou sociaal darwinisme  de zaken wel regelen. Ja, maar… wie betaalt het werk? Erger nog, aangezien het kapitalisme alleen waarde toekent aan werk wanneer het product ervan op een liberale markt wordt verkocht, en die waarde wordt geïndexeerd op de schaarste van het product, hoe worden we dan precies verondersteld gebruikers ervan te overtuigen dat iets gedematerialiseerds, oneindig gratis te downloaden, enige waarde heeft? Veel open-sourceprojecten hebben veel verschillende strategieën geprobeerd om hun werk te financieren, ze zijn allemaal precair en verlamd omdat ze nog steeds een werkstructuur die van nature communistisch is in een kapitalistisch kader willen passen (meer daarover hieronder).

Hoewel non-profitorganisaties kunnen werken voor humanitaire projecten, waar donateurs nooit de beoogde ontvanger van het werk zullen zijn, zijn donaties voor softwareprojecten belanghebbend omdat donateurs gebruikers zijn. Dit onderhoudt een consumentachtig gedrag, waarbij passieve (en enigszins onderdrukte) consumenten wachten op de goederen die worden geleverd door een elitaire minderheid van bestuursleden die de lakens uitdeelt. Die non-profitorganisaties worden nog steeds privaat bestuurd, en het publiek heeft geen ander recht dan te stoppen met doneren als het zich niet gehoord voelt. Het bestuur van de Linux Foundation  is vrijwel uitsluitend samengesteld uit leidinggevenden van hardwareleveranciers en GAFAM , het bestuur van de Free Software Foundation  bestaat uit wetenschappers en computertechnici. Er is daar geen vertegenwoordiging van gebruikers, er zijn verticale hiërarchische structuren van „zij die weten" boven „zij die nodig hebben", die dezelfde soort dominantie bestendigen als het kapitalisme, min de winst.

Dit wordt gerechtvaardigd door het feit dat de open-sourcelicenties elke vorm van verantwoordelijkheid (garantie) van ontwikkelaars tegenover gebruikers afwijzen, wat er een eenrichtingstransactie van maakt die schijnbaar alle beslissingsmacht aan ontwikkelaars geeft. Maar dat alles is natuurlijk een constructie, en geen uitgemaakte zaak. Aan de andere kant brengt de broncode, omdat het kapitalistische dogma zo diep in de hersenen van gebruikers is doordrongen, een software op een vrije, gedematerialiseerde en niet-schaarse markt die elke notie van kapitalistische waarde tenietdoet, waardoor het voor gebruikers oké is om het product van het werk te verkrijgen zonder bijdrage: alweer een eenrichtingstransactie. Ondertussen branden sommige ontwikkelaars op en putten ze zichzelf uit om redelijke gebruikersondersteuning te bieden, zonder een redelijk inkomen te krijgen uit hun (uitgebuite) werk, misschien in de hoop dat het zich op de lange termijn zal uitbetalen, zodra ze het „gemaakt" hebben. Of ontwikkelaars accepteren de onuitgesproken regel van open source (het zou alleen een hobby/deeltijdbezigheid mogen zijn), wat open source onvermijdelijk terugzet, als een voor altijd arme broer van propriëtaire software. Of, ten slotte, worden sommige open-sourcebedrijven zoals Automattic  of RedHat  na verloop van tijd steeds agressiever hebzuchtig, en krijgen ze de tegenreactie van hun gemeenschappen. Dit is niet houdbaar, voor geen van de betrokken partijen.

We moeten die twee parallelle eenrichtingstransacties in een cirkel veranderen. Zo doen we dat:

  1. Geen enkele technologie kan bestaan buiten de samenleving die haar voortbrengt. Technologie heeft wetenschap nodig. Wetenschap heeft onderzoek nodig. Onderzoek heeft structuren nodig waarin het vrij kan worden uitgevoerd. De samenleving is de omgeving waarin dat alles gebeurt, evenals het ondersteuningssysteem dat het mogelijk maakt.
  2. Geen enkele technologie kan bestaan zonder werk. Als het product van het werk ontsnapt aan het kapitalistische systeem (de op schaarste en concurrentie gebaseerde liberale markt), dan zou het werk dat het voortbrengt daar ook aan moeten ontsnappen.
  3. Geen enkele technologie die in privébezit is, zal het algemeen belang en het publieke belang dienen. Technologieën, niet alleen apparaten, zouden eigendom moeten zijn van hun gebruikers, niet alleen van hun makers.
  4. Werk is de enige rijkdom. Werkers zouden moeten profiteren van hun werk, of het nu op een liberale markt wordt verkocht of niet: het zou hoe dan ook betaald moeten worden. Werk zou moeten plaatsvinden in een veilige en eerlijke omgeving. Het is een collectieve, sociale verantwoordelijkheid om dat te laten gebeuren, omdat het product van het werk het algemeen belang en het publieke belang dient. Werk dat die niet dient, zou simpelweg gestopt moeten worden.
  5. Technologieën die eigendom zijn van hun gebruikers openen de weg naar een nieuw soort productie: samenwerking tussen makers en gebruikers, in plaats van concurrentie tussen makers en bedrijfsoorlogen om markten te winnen door klanten te overtuigen van de superioriteit van een bepaald product (waardoor gebruikers uiteindelijk betalen voor reclame…). Maar het kapitalisme weet niet hoe het het product van samenwerking moet verkopen, omdat er geen aparte koper of verkoper meer is, alleen een gemeenschap van personen die samen naar iets toewerken: hun behoeften vervullen, hun theoretische rechten omzetten in werkelijke vrijheid door de context te creëren om ze uit te oefenen.
  6. Er is een wederzijdse verantwoordelijkheid van makers tegenover gebruikers (hun behoeften vervullen via/met technologie), en van gebruikers tegenover makers (hun een veilige en eerlijke werkomgeving en materiële levensomstandigheden bieden). Dit is het absolute fundament van een gemeenschap2
  7. Open source die tot echte vrijheid leidt, kan alleen ontstaan binnen een coöperatieve  structuur. Wat een oud, beproefd en al werkend communisme is, waarbij het bedrijf (en dus het open-sourceproject in het algemeen) eigendom is van zijn klanten en zijn werkers, die de stemmacht delen. Dit gaat veel verder dan een louter afstand doen van intellectueel eigendom (open-source/vrije licentie).

Een coöperatie is een manier om deze tweedeling tussen „wij" en „zij", makers versus gebruikers, te doorbreken, die wederzijds ressentiment voedt: ontwikkelaars zijn de dictators die de applicatie tot hun persoonlijke speeltuin maken, tegenover wie gebruikers altijd dankbaar zouden moeten zijn, hoezeer ze die ook verwoesten, gebruikers zijn de vervelende bloedzuigers die maar cryptische issues en functieverzoeken blijven aandragen, terwijl ze te weinig doneren.

In een coöperatie zijn makers en gebruikers allemaal leden-aandeelhouders. Ze bezitten allemaal het project, ze hebben allemaal één stem in de algemene vergadering. Het project is om fotobewerking vrij te maken voor de nabije toekomst, onder een uniforme visie op wat fotobewerking is (hoe technisch en fijnmazig het zou moeten zijn versus hoe eenvoudig en gebruiksvriendelijk). Om dat doel te bereiken zijn er vele middelen mee gemoeid, zoals onderwijs, belangenbehartiging, documentatie, en uiteraard een softwareapplicatie. Het project is meer dan alleen een eindproduct, dat enige tijd kan nemen om te verschijnen en klaar te zijn: het project is alles daarboven en daaromheen, het is een doel en alle middelen om het tot werkelijkheid te maken.

De verantwoordelijkheid van de leden is om een jaarlijks budget veilig te stellen om alle projectkosten te dekken, hoogstwaarschijnlijk uit jaarlijkse ledenbijdragen. Uit dat budget wordt in de algemene vergadering een bepaald aantal werkuren tegen een bepaald uurtarief besloten. Hoe dit budget zal worden besteed (wat voor soort taken, hardware, gereedschap, enz.) wordt eveneens in de algemene vergadering besloten. Voor technische taken, zoals softwareontwikkeling, zullen dat de hoofdlijnen zijn (zoals het verbeteren van maskeren, batchworkflow, enz.) en niet de implementatiedetails of het eigenlijke ontwerp, die slecht geschikt zijn voor democratische processen. Ontwikkelaars zouden backend-gerichte taken kunnen aandragen (zoals het herschrijven of refactoren van technische schuld, om de onderhoudskosten op lange termijn te verlagen), gebruikers zouden functiegerichte taken kunnen aandragen (zoals het ondersteunen van nieuwe camerafuncties, beeldformaten, enz.): het doel van de algemene vergadering is te beraadslagen en prioriteiten te rangschikken.

De overeengekomen taken zullen vervolgens door betaalde werkers worden aangepakt in volgorde van prioriteit totdat het werkbudget is verbruikt. Dit is niet beperkt tot technologisch werk en ontwikkeling, maar geldt voor elk soort werk dat vooraf is overeengekomen. Wanneer het budget is verbruikt, zullen werkers rapporteren waar ze zijn gestopt in de todolijst, wat ze hebben kunnen afronden, wat niet, en welke middelen ontbraken om af te ronden. De algemene vergadering zal vervolgens beslissen of het mogelijk en wenselijk is om meer middelen te investeren om af te ronden, of om de resterende taken door te schuiven naar het volgende jaarlijkse budget. Dit geeft werkers zicht op hun jaarlijkse inkomen zonder overcommitment en burn-out te bevorderen.

Gebruikers kunnen panels vormen om met ontwikkelaars samen te werken aan het begrijpen van de daadwerkelijk ondervonden problemen, oplossingen te testen en te valideren in een ontwerpproces. Elke gebruiker kan tot werker worden omgezet en inkomen gaan verzamelen voor zijn werk aan overeengekomen taken, na goedkeuring van de algemene vergadering.

Dit maakt het ieders verantwoordelijkheid om ervoor te zorgen dat de middelen om vooruit te komen worden verzameld, en om werkers te geven wat ze nodig hebben om fatsoenlijk, veilig en zonder uitgebuit te worden te werken. Geen enkele hoeveelheid werk zou gratis mogen zijn, ongeacht de taak. Werk zou niet beperkt mogen zijn tot programmeren of andere technische taken.

De grenzen van de democratie

Democratie via stemming is in wezen het uitdrukken van de wil van de meerderheid, waarvan bekend is dat die minderheden onderdrukt. Het is daarom niet perfect. Minderheden kunnen redelijke en legitieme zorgen uiten, alleen zullen die niet door de meerderheid worden gedeeld. Personen met een handicap komen voor de geest: sommige ontwerpdetails kunnen de hele applicatie voor hen volkomen onbruikbaar maken, ook al hebben ze niet de aantallen om hun standpunten in een stemming op te leggen. Aan de andere kant is het niet mogelijk om aan ieders eigenaardige behoeften tegemoet te komen zonder monsters te creëren. Dit moet zorgvuldig worden geëvalueerd en beslecht.

De verantwoordelijkheid van de meerderheid is daarom om te identificeren wie de structurele minderheden zijn, dat wil zeggen welke eigenschappen die minderheden samenbinden (gezondheidstoestand, sociale afkomst, opleiding, inkomensniveau, enz.). Als een minderheid een probleem aankaart dat voor hen blokkerend is vanwege een van de bepalende eigenschappen van die minderheid, zou er een manier moeten zijn om de meerderheidsstem te omzeilen of opnieuw te wegen. Dit moet nog worden gedefinieerd, maar de eenvoudigste manier om dit te omvatten is tijdens de beraadslagingen, die berusten op de empathie en het begrip van de meerderheid.

Een ander probleem van elke sociale groep is groepsdenken , omdat elke sociale groep na verloop van tijd de neiging heeft te verworden tot een clubje. Groepsdenken is wanneer individuen zich niet vrij voelen om kwesties aan te kaarten die tegen de (vermeende) groepsconsensus ingaan, uit angst voor gevolgen voor hun plaats en aanzien in de groep. Die gevolgen kunnen erg subtiel maar toch heel reëel zijn. Het wordt schadelijk wanneer individuen binnen de groep beslissingen gaan steunen die ze op zichzelf niet zouden hebben gesteund: dit is het kantelpunt waarop de individuele rationaliteit verloren gaat. Om dit te vermijden kan anoniem stemmen worden gebruikt, maar dat is niet van toepassing op beraadslagingen waar er noodzakelijkerwijs een spreker is. Er is een cultuur van gezonde onenigheid op te bouwen, te onderhouden en aan te moedigen. Een manier om dit probleem op te lossen is door voor elke sessie willekeurig een „advocaat van de duivel" aan te wijzen, wiens taak het zal zijn om het voortdurend oneens te zijn en de bijbehorende argumenten uiteen te zetten.

Van elke gemeenschap die gebaseerd is op een gedeelde interesse in fotografie en vrije software valt te verwachten dat ze bevooroordeeld is ten gunste van rijke, opgeleide, computervaardige, Engelstalige mannen. Het zal een bewuste inspanning moeten zijn om te proberen vrouwen, minder opgeleide personen, niet-westerse burgers, enz. erbij te betrekken. In combinatie met democratie-via-stemming en groepsdenken kan het echt schadelijk zijn om met zo’n sociaal homogene groep te beginnen, als het niet zorgvuldig wordt beheerd. Dit zal een dagelijkse uitdaging zijn waar iedereen zich bewust van moet zijn. Het zal ook de survivorship bias  voeden, waarbij de buitengeslotenen er niet zijn om feedback te geven over waarom ze zich niet aansloten, deelnamen of welkom voelden, en buitengeslotenen zullen extra zorg nodig hebben om bereikt en verwelkomd te worden.3 Geen enkele mate van racisme of seksisme kan in zo’n omgeving worden getolereerd, zelfs niet als grap, want dat zou de meerderheid laten lachen ten koste van minderheden in een context waaruit ze al zijn weggefilterd.

Democratie is ook een traag proces. Er kunnen dingen gebeuren die een prompte beslissing vereisen, zoals een beveiligingslek in de projectserver of socialemedia-accounts, of enige dringende juridische kwestie. Iemand zou verkozen moeten worden voor kortlopende mandaten om die beslissingen snel namens de gemeenschap te kunnen nemen.

De grenzen van experts versus leken

Net als artsen of advocaten hebben ontwikkelaars nichecompetenties en -ervaring, die hen een zekere macht en zelfs charisma over leken zullen geven. Deze macht kan worden misbruikt om de meerderheid te onderdrukken door haar gebrek aan kennis uit te buiten ten gunste van de onderdrukker. Deze relatie zal altijd asymmetrisch zijn, en dat moet worden erkend. Ook zullen ontwikkelaars tijdens de beraadslagingen in de algemene vergadering geraadpleegd moeten worden, om de haalbaarheid van taken en de benodigde middelen te beoordelen, voordat er gestemd wordt.

Net als artsen, advocaten, enz. zouden ontwikkelaars een soort ethische code moeten hooghouden die bij hun symbolische macht hoort, waaronder:

  1. een plicht om eerlijk te informeren, naar beste weten, en om eenvoudig uit te leggen wat eenvoudig uitgelegd kan worden,
  2. een plicht tot behoorlijke procesgang en zorgvuldigheid bij het onderzoeken en ontwikkelen van oplossingen,
  3. een verbintenis om te werken in het beste belang van de gemeenschap.

Aan de andere kant kunnen ontwikkelaars (of andere experts) door leken worden gezien als alwetende, almachtige tovenaars, die dan te veel van hen kunnen vragen. Hoewel software een vrij kneedbaar medium is, zijn er toch niet-onderhandelbare technische beperkingen die van toepassing zijn, en alles wat technisch mogelijk is, is misschien niet mogelijk binnen de huidige omstandigheden met de huidige middelen.

Beide standpunten zullen begrepen moeten worden om te voorkomen dat er wederzijds ressentiment ontstaat.

De grenzen van samenwerking

Iedereen is een ontwerper.

Elke baan waar je niets van weet, lijkt gemakkelijk te doen. Het ontwerpen en bouwen van technische objecten is er daar een van. Het is zelfs opwindend om eraan bij te dragen. Maar een software die door duizenden gebruikers naast jezelf als gereedschap zal worden gebruikt, is niet hetzelfde als je eigen nachtkastje.

Gebruikers zouden welkom moeten zijn om deel te nemen aan de probleemdefinitie: begin bij een of meerdere gebruikers die een bepaald probleem hebben in een bepaalde workflow, kijk of dat niet al opgelost kan worden met de huidige gereedschappen en misschien wat scholing, en zo niet, probeer dan te onderzoeken hoeveel gebruikers hetzelfde probleem delen. Als het probleem niet voor iedereen precies hetzelfde is, probeer dan een gemeenschappelijke uitdrukking van het probleem te vinden die het mogelijk maakt om het te veralgemenen.

Zodra het probleem is gedefinieerd, begint het ontwerpproces, dat formele stappen volgt om te voorkomen dat men naar de eerste (en hoogstwaarschijnlijk niet-optimale) oplossing racet, want, nogmaals, de menselijke intuïtie is beter in het bouwen van nachtkastjes dan van gereedschap dat door duizenden wordt gebruikt. Maar het volgen van het proces is niet genoeg.

Psychologie en cognitiewetenschappen convergeren naar een consensus: de beste grootte voor werkteams ligt tussen de 4 en 7 leden. Vanaf 8 leden begint de productiviteit dramatisch te dalen.456 Voor een team van 4 leden zijn er 6 interpersoonlijke communicatiekanalen, terwijl er voor 8 leden 28 communicatiekanalen zijn. Dit maakt het cognitief moeilijk om iedereen die erbij betrokken is bij te houden, wie waarvoor verantwoordelijk is, non-verbale signalen te verwerken, wat communicatieoverbelasting creëert. Boven de 9 leden beginnen zich clans te vormen, raakt politiek verweven in het proces, en doet social loafing  zijn intrede.45

Dit betekent dat het werk zou moeten worden opgesplitst in werkteams die elk niet meer dan 6 tot 7 leden hebben, ook al zou het voor de gemeenschap in het algemeen opwindend kunnen worden om in alles geïnteresseerd te raken. Communicatie is hier het kantelpunt: je hebt er precies de juiste hoeveelheid van nodig, niet meer, niet minder, anders verzadigt het teamleden cognitief en belemmert het de communicatie zelf. Daar is het het werk zelf dat een klap krijgt.


Translated from English by : Claude. In case of conflict, inconsistency or error, the English version shall prevail.

  1. Aurélien Pierre, Who are the Darktable users in 2020 ?, 2023. URL ↩︎

  2. Unfortunately, the definition of “community” in the open-source world is more like a group of guys who get excited about the same techs, rather than a group of people who take care of each other. ↩︎

  3. Which is why attending free-software-centric graphics/imaging events is probably not a good investment. ↩︎

  4. HACKMAN, J. Richard. Leading teams: Setting the stage for great performances. Harvard Business Press, 2002. URL  ↩︎ ↩︎

  5. WHEELAN, Susan A. Group size, group development, and group productivity. Small group research, 2009, vol. 40, no 2, p. 247-262. URL  ↩︎ ↩︎

  6. ALLEN, Natalie J. et HECHT, Tracy D. The ‘romance of teams’: Toward an understanding of its psychological underpinnings and implications. Journal of occupational and organizational psychology, 2004, vol. 77, no 4, p. 439-461. URL  ↩︎