Després de la sortida d'Héctor Martin com a mantenidor de la plataforma ARM/Apple a la branca principal del nucli, s'ha obert un nou capítol en el manteniment del nucli, ja que ara, Karol Herbst, qui exercia un rol fonamental (era l'encarregat del controlador Nouveau i de l'eina de seguiment MMIO), ha decidit també retirar-se de les seves funcions com a mantenidor i deixar de participar en la revisió de pegats.
Sobre la seva decisió, Karol Herbst va emfatitzar que, malgrat la seva partida, dos mantenidors seguiran recolzant el controlador, complint una tasca que ell considera com «una gran feina».
la decisió de Karol es basa en el seu descontentament per la manca d'un ambient inclusiu dins del grup de desenvolupadors principals, on, en la seva visió, la col·laboració s'hauria de fonamentar en el respecte mutu i l'equitat, sense permetre que certs poders tàcits influeixin en el procés.
La controvèrsia es va intensificar després de la publicació de Theodore Ts'o, que va va utilitzar la metàfora d'una “prima línia blava” per descriure el rol dels mantenidors, comparant-los amb una barrera que separa l'ordre de l'anarquia i que assegura la qualitat i la sostenibilitat del codi acceptat.
T'explicaré un secret: els encarregats del manteniment no són «todopoderosos».
Són la «prima línia blava» que intenta mantenir el codi dret, mantenible i d´alta qualitat. Com la majoria dels líders de voluntaris de organització, ja sigui el Grup de Treball d'Enginyers d'Internet (el organisme de normalització per a Internet), en realitat tenim molt poc poder.
No podem *ordenar* a les persones que treballin per cancel·lar el deute tècnic, o que meixorar la infraestructura de proves o treballar en alguna característica en particular que ens agradaria molt per als nostres usuaris.Tot el que podem fer és impedir que s'acceptin les coses (ja sigui a la nostra
subsistema, o l'imprimatur de l'IETF). Amb sort, només estem
Aturar el progrés de les coses dolentes, però això *realment* és tot el que podem fer.
Per a Karol, emprar semblant analogia resulta inacceptable, perquè ignora l'impacte negatiu que pot tenir en aquelles persones marginades i en la percepció d'una comunitat que hauria de ser inclusiva.
Al debat es destaca, a més, que els mantenidors, encara que essencials per evitar la incorporació de canvis inestables o deficients, perden part de la seva influència una vegada que el codi és integrat al nucli, quedant responsables de les conseqüències posteriors. Aquest escenari s'agreuja quan equips interessats únicament a promocionar les seves creacions desapareixen després de l'acceptació del codi, deixant els mantenidors amb l'àrdua tasca de corregir errors.
Una de les coses que resulta molt frustrant per part del mantenidor
La perspectiva són els equips de desenvolupament que només estan interessats en la seva mascota característica, i *sabem*, per experiència molt amarga, que més del 95% del temps, una vegada que el codi és acceptat…El codi desapareixerà i mai més no es tornarà a veure. Com a resultat d'una dinàmica comuna, és que els mantenidors exerciran l'únic i exclusiu poder que tenen — que és negar-se a acceptar el codi fins que és pràcticament perfecte — ja que una vegada que acceptem el codi, instantàniament perdrem tot palanquejament, i els contribuents desapareixeran, i nosaltres… quedar amb la responsabilitat de netejar el desastre.
la situació també ha posat de manifest un aparent doble moral en el procés d'integració de canvis: mentre que el treball de desenvolupadors “consentits” s'aprova de manera gairebé immediata, les propostes de nous integrants enfronten una revisió molt més rigorosa per demostrar-ne la fiabilitat, encara que en aquest últim cas podríem entendre el perquè, ja que un exemple molt pràctic n'és el cas de la utilitat «XZ».
Pel que fa a l'altra cara de la moneda, hi ha el cas del compilador Clang, els canvis del qual van trigar una dècada a consolidar-se dins del procés de construcció del nucli, cosa que evidencia la necessitat de temps i confiança perquè les innovacions radicals s'integrin de manera segura.
Sens dubte, tot això que sorgeix dins de l'equip de desenvolupadors de Linux es convertirà una de les bases que ajudés a fomentar un entorn on la diversitat i el respecte siguin pilars fonamentals de la col·laboració en el codi obert.