Wat is er mis met Wikiwijs?

Twee uitspraken over het onderwijs: het kopieerapparaat is het meest gebruikte apparaat in de school en docenten gebruiken nog liever elkaars tandenborstel dan elkaars lesmateriaal. Dat klinkt tegenstrijdig, maar volgens mij bevatten ze allebei een kern van waarheid. Ik heb als leerling genoeg (soms letterlijk) bij elkaar geknipte readers en toetsen gekregen, maar ik heb ook nog nooit een docent gezien die een gegeven lesplan zo uitvoerde als het op papier staat. En dat is ook logisch, want je wilt niet het wiel steeds opnieuw uitvinden (laat staan dat je daar tijd voor hebt), maar je wilt wel dat een les en het materiaal aansluiten bij je eigen, steeds veranderende context.

Pleitbezorgers van open lesmateriaal beloven docenten materiaal dat ze mogen kopiëren, makkelijk aan kunnen passen en verbeteren, en vervolgens verder delen. Dit lijkt echter maar moeilijk van de grond te komen: kopiëren lukt nog wel, maar tot aanpassen, verbeteren en verder delen komt het in de praktijk zelden. Volgens mij ligt dat niet aan het principe, maar aan het ontbreken van structuren en tools om die belofte van makkelijk aanpassen en delen waar te maken. In deze post wil ik onderzoeken waar dat door komt en welke structuren we nodig hebben om het (misschien) wél een succes te laten worden.

Het probleem van Wikiwijs

Op het gebied van open lesmateriaal moeten we het in Nederland hebben over Wikiwijs, zelfverklaard “dé plek voor open en gratis lesmateriaal.” Op Wikiwijs kan iedereen lesmateriaal schrijven en publiceren, onder de voorwaarde dat anderen het materiaal mogen aanpassen en opnieuw delen. In Wikiwijs-taal: iedereen kan een eigen variant van het materiaal maken en daarin zo veel of zo weinig aanpassen als ze maar willen.

Daarmee maakt Wikiwijs de belofte van open lesmateriaal in principe waar. Wat is er dan mis mee? Het gevolg van deze aanpak is dat er een zee aan materiaal en varianten bestaat en niemand precies weet welk materiaal goed of zelfs populair is. Laat staan dat duidelijk is welke variant van dat materiaal het beste onderhouden wordt en welke varianten alleen zijn aangepast om binnen de eigen context te gebruiken. Met gecureerde verzamelingen door redacteuren probeert men daar nu wat orde in te brengen, maar ik denk dat Wikiwijs (in de huidige vorm) niet het beste gereedschap is om een meer op open samenwerking gerichte cultuur te faciliteren.

Wat wel werkt

Om te begrijpen waar het bij Wikiwijs aan schort, is het nuttig om te kijken naar modellen van open en vrije informatie die wel werken: de wiki, waarvan Wikipedia het grootste voorbeeld is, en vrije software en opensourcesoftware (free and open-source software, FOSS), met Linux als onwaarschijnlijk groot succes. Zowel Wikipedia als Linux worden actief gebouwd door duizenden mensen die grote of kleine bijdrages leveren aan het project. Bij beide projecten staan waarden van vrijheid centraal, maar de technische organisatie van beide projecten zit volstrekt anders in elkaar.

Vrijheden

Vrijheid is het grondbeginsel van beide systemen. De derde zuil van Wikipedia is dat alle inhoud “vrij” is, wat betekent dat de teksten door iedereen overgenomen, gewijzigd en verspreid mogen worden, op voorwaarde dat de bron wordt vermeld en dat wijzigingen onder dezelfde vrije voorwaarden beschikbaar worden gemaakt. Op Wikipedia wordt dit gewaarborgd door de CC-BY-SA-licentie. Die vrijheden en voorwaarden zijn zeer vergelijkbaar met populaire FOSS-licenties, zoals de GPL. Licenties voor vrije software waarborgen de vier “essentiële vrijheden” om software te mogen gebruiken, bestuderen, aanpassen en verder verspreiden, zowel in originele als aangepaste vorm. Deze vrijheden maken de grootschalige samenwerking, waarop beide systemen bouwen, mogelijk, maar volgens mij is alleen de licentie niet voldoende voor een succesvol project. Daar horen ook een cultuur en een technische ondersteuning van die cultuur bij, wat bij Wikipedia en bij FOSS op twee verschillende manieren goed is geslaagd.

Waarom Wikipedia werkt

Op Wikipedia is iedereen eigenaar van de wiki en werkt iedereen aan dezelfde Wikipedia.¹ Iedere voorbijganger mag de wiki aanpassen. Hopelijk is die aanpassing een verbetering, maar dat is natuurlijk niet gegarandeerd. Om problemen te voorkomen, worden in de wiki alle wijzigingen bijgehouden in de bewerkingsgeschiedenis. De wiki is daarmee vergelijkbaar met een groot gedeeld bestand: er is altijd één versie, namelijk de nieuwste versie die je te zien krijgt als je een pagina op de wiki leest en waarin je je wijzigingen maakt. Daardoor is de bewerkingsgeschiedenis lineair: iedere wijziging bouwt voort op de vorige. Ook het ongedaan maken van een wijziging is simpelweg een nieuwe verandering, als je de bewerkingsgeschiedenis bekijkt.

De bewerkingsgeschiedenis is voor iedereen transparant terug te zien en wijzigingen daarin die niet bijdragen aan de encyclopedie kunnen ook door iedereen weer ongedaan gemaakt worden, net zoals dat iedereen alle pagina’s mag bewerken. Er is dus geen “eigenaar” van de wiki of van een bepaald artikel en wijzigingen hoeven niet van tevoren goedgekeurd te worden door mensen met speciale rechten.² Natuurlijk zijn er normen en gedragsregels en als je je daar niet aan houdt, dan kan het recht om wijzigingen aan te brengen je wel ontzegd worden. Op Wikipedia komen die normen voort uit een aantal waarden die Wikipedia maken tot wat het is, te beginnen met de eerste zuil die een helder doel stelt: “Wikipedia is een encyclopedie.”

Dat laatste is een van de redenen dat Wikipedia werkt: iedereen die bijdraagt aan Wikipedia heeft uiteindelijk hetzelfde doel, namelijk een encyclopedie schrijven. Daardoor kan er één Wikipedia zijn waarin iedereen samenwerkt.

Waarom FOSS werkt

Waar bij Wikipedia iedereen centraal aan dezelfde versie werkt, ziet dat er bij de meeste FOSS-projecten anders uit. In de meeste gevallen is er expliciet geen centraal systeem, maar wordt alles decentraal geregeld. Iedereen heeft wel de vrijheid om aanpassingen te maken aan de software, maar die komen niet automatisch terecht in de “officiële” versie, zoals dat in Wikipedia gebeurt. Dat heeft tot gevolg dat er geen lineaire geschiedenis meer is: jij kunt in jouw versie een nieuwe feature toevoegen, terwijl ik in mijn kopie een bug verhelp. Nu hebben we als het ware twee “nieuwste versies”.

De kracht van decentrale versiebeheersystemen (zoals git) zit hem in de mogelijkheid om die uiteenlopende wijzigingen weer samen te kunnen voegen (een “merge”, in vaktermen), in veel gevallen zelfs automatisch. Eigenaarschap ziet er daarmee ook heel anders uit: op Wikipedia is niemand eigenaar van de wiki, maar in FOSS is iedereen eigenaar van hun eigen kopie. Naar de buitenwereld is vaak één kopie de “officiële” versie van het project: bij Linux is die mainline-versie bijvoorbeeld de kopie van Linus Torvalds, die wijzigingen uit de kopieën van vele Linux-ontwikkelaars samenvoegt. Voor Linux komen die wijzigingen per e-mail bij Linus binnen, maar voor de meeste projecten gaat dat via een pull request in hun git forge naar keuze (zoals GitHub, GitLab of Forgejo). De eigenaar van de kopie heeft daarbij de controle over welke wijzigingen wel en niet worden overgenomen.

Het hoeft ook niet zo te zijn dat er een enkele “officiële” versie is. Van Linux zijn er vele distributies te krijgen, die allemaal op hun eigen manier verschillende FOSS-projecten samenvoegen tot een bruikbaar besturingssysteem. Een aantal daarvan hebben daarbij hun eigen kopie van de kernel, bijvoorbeeld Ubuntu, Fedora of Android, waarin ze extra wijzigingen doorvoeren die voor hun specifieke project van toepassing zijn, maar die niet passen in de algemene Linuxkernel. Zo voegt Ubuntu het ZFS-bestandssysteem toe als een standaardmodule in hun kernels en bevatten verscheidene Android-kernels speciale drivers om met bijzondere telefoonhardware om te gaan. Dit kan alleen werken met een systeem waarbij je verschillende uiteenlopende wijzigingen weer samen kunt voegen, zodat alle algemene verbeteringen in de mainline van Linus moeiteloos geïntegreerd kunnen worden met de bijzondere wijzigingen die binnen die projecten zijn aangebracht.

Het grote succes van FOSS zit hem er dus niet in dat iedereen hetzelfde doel heeft, want dat is niet het geval, maar dat we tools hebben die ervoor zorgen dat we wel gezamenlijk het overlappende deel van onze doelen kunnen doorontwikkelen, zonder elkaar onze particuliere wijzigingen op te dringen.

Lesmateriaal in een wiki?

Terug naar Wikiwijs: waarom lijkt dat model nou niet te werken? Alle inhoud op Wikiwijs is beschikbaar onder een CC-BY- of CC-BY-SA-licentie, waarbij dezelfde vrijheden worden gewaarborgd als op Wikipedia en bij vrije software, dus daar kan het niet aan liggen. Een van de redenen dat Wikiwijs, wat mij betreft, minder goed is geslaagd dan we zouden willen, is de gekozen organisatiestructuur: daar komen ideeën van zowel de wiki als van FOSS samen, maar op zo’n manier dat de samenwerking die bij beide zo goed werkt, hier juist moeilijk wordt gemaakt.

Aan de ene kant is Wikiwijs een centraal platform en presenteert het zich (alleen al door de naam) als een soort Wikipedia voor lesmaterialen. Tegelijkertijd is er ook een sterk model van eigenaarschap, want niet iedereen kan zomaar aanpassingen maken in het gepubliceerde materiaal. Als je het materiaal wilt aanpassen, dan maak je daarvoor een eigen “variant” (kopie, fork), waarvan jij dan de eigenaar bent en waarin je naar believen wijzigingen kunt aanbrengen. Dat is dus het decentrale model van vrije software,³ maar de functionaliteit van het automatisch samenvoegen van wijzigingen of het sturen van pull requests ontbreekt. Dat maakt het lastig om verbeteringen in de originele kopie over te nemen, met als gevolg dat er een wirwar van verschillende versies van iedere module ontstaat, zonder duidelijke indicatie wat de “officiële”, meest recente, of “beste” versie is en welke versies actief onderhouden worden. Zo hebben we het slechtste van twee werelden.

Zijspoor: de Neon-variant

Neon is een nieuwe speler in het veld van lesmateriaal. Niet met een vrij en/of open model, maar als een coöperatie van scholen (lees: schoolbesturen⁴). Neon heeft auteurs in dienst om het lesmateriaal in de eerste plaats te schrijven, maar ze zien ook de waarde in van vrijheid om materiaal aan te passen aan de lokale context. Docenten kunnen binnen de Neon-omgeving een eigen variant van het materiaal maken, die dan ook weer binnen de coöperatie gedeeld kan worden. Ze lijken daarbij een kwaliteitstoets te willen hanteren om een wildgroei zoals bij Wikiwijs te voorkomen, waarmee de vrijheid om te delen dus sterk zou worden ingeperkt. Het is op dit moment niet duidelijk in hoeverre verbeteringen in de originele methode bijvoorbeeld makkelijk in die varianten geïntegreerd kunnen worden. Er lijken ook ambities te zijn om de techniek breder dan alleen binnen Neon bruikbaar te maken via de Open Education Foundation, maar “open” zou ik dat (op moment van schrijven (nog)) niet willen noemen.

Overigens heeft Neon technisch een interessant platform, met onder andere de mogelijkheid om printversies met en zonder invulvelden en docentenversies met antwoorden en suggesties voor lesplanningen allemaal te genereren vanuit hetzelfde bronmateriaal. Ze maken ook goed gebruik van hun structuur met bijvoorbeeld de optie om iedere sectie aan leerdoelen en eindtermen te koppelen. Het zou me dus niet verbazen als ze ook een goede oplossing hebben om varianten up-to-date te houden met het originele materiaal, maar tot nog toe heb ik daar niets over kunnen vinden.

Kan het wel?

Terug naar de wiki: is dat überhaupt een goed model voor lesmateriaal? We zouden van Wikiwijs moeiteloos een echte wiki kunnen maken: er is één versie en iedereen die wil bijdragen, maakt wijzigingen in die ene versie. Het nadeel daarvan is echter dat het lesmateriaal te allen tijde kan veranderen, wat natuurlijk niet ideaal is halverwege een lessenserie. Dat kun je oplossen met snapshots, links naar een specifieke versie, maar dan gaat het toch al snel richting de varianten die nu in Wikiwijs voor chaos zorgen. Daarnaast gaat het compleet voorbij aan wijzigingen die docenten willen maken om het materiaal binnen hun eigen context te plaatsen, die voor de rest van de wereld helemaal niet een verbetering of überhaupt interessant zijn. De wiki is simpelweg niet het juiste model voor lesmateriaal.

Volgens mij zijn er twee soorten wijzigingen in lesmateriaal, die we op verschillende manieren moeten benaderen. Aan de ene kant zijn er algemene aanpassingen en uitbreidingen, die het materiaal verbeteren en voor iedere gebruiker interessant kunnen zijn. Aan de andere kant zijn er particuliere wijzigingen, die het materiaal passend maken in een specifieke lescontext.⁵ Sommige daarvan zijn wellicht de moeite waard om te delen, andere zijn zo specifiek dat niemand daar behoefte aan heeft. De algemene verbeteringen willen we dus breed met iedereen delen en het liefste invoegen in de “officiële” versie, maar de particuliere wijzigingen houden we voor onszelf. Tegelijkertijd moeten we de algemene verbeteringen wel eenvoudig in onze eigen variant kunnen invoegen. Moeten we dan niet gewoon het FOSS-model hanteren?

Ik denk dat dat inderdaad de betere weg is, maar het is helaas niet zo simpel om dan al het lesmateriaal maar in git te zetten, de tool die voor veel FOSS-projecten wordt gebruikt. Dergelijke tools zijn gericht op programmacode, die qua structuur anders in elkaar steekt dan een schoolboek of lesmateriaal. Een van de typische wijzigingen die een systeem aan zou moeten kunnen, is het veranderen van de volgorde van hoofdstukken of het toevoegen en weglaten van oefeningen. Als we het boek als een tekstbestand in versiebeheer zetten, dan ziet een verplaatsing van een hoofdstuk eruit als een verwijdering van een groot stuk tekst en een losstaande toevoeging van een groot stuk tekst. Een verbetering die in de originele versie in een hoofdstuk is gemaakt, is daardoor niet meer automatisch door te voeren in onze aangepaste variant. Technisch is daar wel een mouw aan te passen,⁶ maar het is wel een uitdaging om dat op een manier te doen die voor een normale docent te begrijpen en te gebruiken is.

Wat te doen?

Ik denk nog steeds dat open lesmateriaal kan werken. En ik denk ook dat het een goede oplossing kan zijn voor het probleem dat docenten hun materiaal willen aanpassen aan de context, maar wel op een gedegen basis willen voortbouwen. De structuren en systemen die we er nu voor hebben, bieden echter geen oplossing voor de echte problemen: materiaal online zetten is niet per se moeilijk, en er zijn zat systemen om interactieve oefeningen en andere leuke dingen in je lesmateriaal te bouwen, maar het samenvoegen van wijzigingen is in de bestaande platformen niet opgelost. Dat is zonde, want technisch kan het: programmeurs wereldwijd gebruiken elke dag tools die dat doen. De uitdaging is om lesmateriaal op zo’n manier te structureren dat we dergelijke tools kunnen gebruiken én dat docenten er nog mee overweg kunnen. Daar zouden we aan moeten werken.