Na het vertrek van Hector Martin als maintainer en het stoppen van zijn deelname aan het beoordelen van patches, heeft Karol Herbst (Karol Herbst), die de Nouveau-driver en het MMIO-traceermechanisme (MMIOTRACE) begeleidde en werkzaam was bij Red Hat, ook zijn verantwoordelijkheden neergelegd. Na zijn vertrek blijven er nog twee maintainers over die de Nouveau-driver ondersteunen en die, volgens Karol, uitstekend werk afleveren.
Als reden voor zijn vertrek wordt het gebrek aan inclusiviteit in de omgeving van kernel-ontwikkelaars genoemd. Karol is ervan overtuigd dat binnen de gemeenschap die zich bezighoudt met de ontwikkeling van open source software, de samenwerking moet plaatsvinden met respect, op gelijke voet en zonder machtsmisbruik. Volgens Karol was de druppel die de emmer deed overlopen een bericht van Theodore Ts'o, waarin hij maintainers vergeleek met de 'dunne blauwe lijn' (geassocieerd met wetshandhaving en symboliseert de grens tussen orde en anarchie), die erop gericht is ervoor te zorgen dat de code die in de kernel wordt opgenomen, onderhoudbaar en van hoge kwaliteit is.
Volgens Karol kan iemand die zulke woorden uitspreekt geen rol als maintainer vervullen, ongeacht hoe belangrijk hij is voor het project, en hij moet worden uitgesloten voordat hij beseft wat deze woorden betekenen voor veel gemarginaliseerde mensen en welke verschrikkingen ze in hun geest oproepen. Karol vertrekt omdat hij niet in een gemeenschap kan blijven waar zulke woorden worden geduld.
Theodore Ts'o maakte de vergelijking met de dunne blauwe lijn tijdens een discussie over de weerstand van oudere ontwikkelaars tegen het vooruitstrevend van Rust in de kernel. Hij schreef dat de macht van de maintainers beperkt is en dat zij geen invloed kunnen uitoefenen op de voortzetting van de ontwikkeling van al geaccepteerde wijzigingen, omdat ze niet de mogelijkheid hebben om mensen te dwingen aanpassingen te maken en de testinfrastructuur te verbeteren. Het enige hulpmiddel voor kwaliteitsborging is de mogelijkheid van de maintainers om te voorkomen dat onvolwassen en twijfelachtige wijzigingen in de kernel worden opgenomen. Zodra de code is geaccepteerd, verliezen maintainers hun invloed op de ontwikkelaars en worden zij persoonlijk verantwoordelijk voor deze code.
Bij aanzienlijke veranderingen moeten de maintainers ervoor zorgen dat de wijziging volledig functioneel is en dat de ontwikkelaars in staat zijn om de code te onderhouden na acceptatie in de kernel, en deze code niet onbeheerd achterlaten. Theodor citeert als voorbeeld teams die alleen geĆÆnteresseerd zijn in de voortgang van hun project, die zodra de code is geaccepteerd verdwijnen en niet meer terugkomen, terwijl de maintainers alle gebreken moeten oplossen die zijn ontstaan.
Er zijn beschuldigingen van dubbele standaarden, omdat de code van sommige ontwikkelaars bijna onmiddellijk wordt geaccepteerd, terwijl de code van anderen langdurig moet worden behandeld. In deze kwestie is het gevestigde vertrouwen en de verdiende reputatie van belang. Als een ontwikkelaar eerder heeft aangetoond verantwoordelijk te kunnen zijn voor de aangebrachte wijzigingen ā dan gaan de goedkeuringen snel. Voor nieuwkomers kan de acceptatie van wijzigingen langer duren, omdat de begeleider moet begrijpen of de deelnemer verantwoordelijk kan zijn voor zijn code. Daarom moeten deelnemers, vooral degenen die radicale veranderingen willen doorvoeren, veel tijd besteden aan het worden van een deel van de gemeenschap. Bijvoorbeeld, de integratie van wijzigingen voor de kernelbouw met de Clang-compiler kostte 10 jaar.
Bron: opennet.ru
