Po odejściu Hectora Martina ze stanowiska maintainer-a i zaprzestaniu recenzowania paczek, Karol Herbst, który koordynował sterownik Nouveau oraz mechanizm śledzenia MMIO (MMIOTRACE) w firmie Red Hat, również ogłosił swoją rezygnację. Po jego odejściu w jądrze pozostaną jeszcze dwaj maintainerzy obsługujący sterownik Nouveau, którzy, według Karola, doskonale radzą sobie ze swoimi obowiązkami.
Jako powód odejścia podano brak atmosfery inkluzyjności wśród deweloperów jądra. Karol jest przekonany, że w społeczności zajmującej się rozwojem otwartego oprogramowania praca powinna być prowadzona z szacunkiem, na równi i bez wykorzystywania władzy. Według Karola, kroplą, która przelała czarę goryczy, było stwierdzenie Theodore'a Ts'o, który porównał maintainerów do "cienkiej niebieskiej linii" (identyfikowanej z organami ścigania, symbolizującej granicę między porządkiem a anarchią), starającej się, aby kod włączany do jądra był wspierany i wysokiej jakości.
Zgodnie z opinią Karola, osoba, która wygłasza takie słowa, nie może zajmować stanowiska opiekuna, niezależnie od tego, jak ważna jest dla projektu, i powinna zostać wykluczona, zanim zrozumie, co te słowa znaczą dla wielu zmarginalizowanych ludzi oraz jakie przerażenie wywołują w ich umysłach. Karol odchodzi, ponieważ nie może pozostawać w społeczności, która toleruje takie wypowiedzi.
Theodore Ts'o przytoczył porównanie do cienkiej niebieskiej linii podczas dyskusji na temat oporu starych programistów przed wprowadzeniem Rust do jądra. Napisał, że władza maintainerów jest ograniczona i nie mogą oni wpływać na dalszy rozwój już zaakceptowanych zmian, ponieważ nie mają możliwości nakazania ludziom zajmowania się poprawkami i ulepszaniem infrastruktury testowej. Jedynym narzędziem zapewnienia jakości jest zdolność maintainerów do zablokowania włączenia do jądra nieprzygotowanych i budzących wątpliwości zmian. Gdy kod zostanie zaakceptowany, maintainerzy tracą wpływ na programistów i stają się osobiście odpowiedzialni za ten kod.
W obliczu znaczącej zmiany, główni deweloperzy muszą mieć pewność, że zmiana jest w pełni funkcjonalna, a jej twórcy mogą wspierać kod po jego przyjęciu do jądra i nie pozostawią go bez nadzoru. Teodor przytacza jako przykład zespoły, które są zainteresowane tylko promowaniem swojego dzieła, które po przyjęciu kodu znikają i nie pojawiają się ponownie, podczas gdy główni deweloperzy muszą radzić sobie ze wszystkimi niedociągnięciami.
Niektórzy zarzucają podwójne standardy, wskazując na to, że kod jednych deweloperów jest akceptowany niemal od razu, podczas gdy kod innych długo się obraca. Ważne jest tutaj zaufanie i zasłużona reputacja. Jeśli deweloper już udowodnił swoją zdolność do odpowiedzialności za wprowadzone zmiany, akceptacje przebiegają szybko. Dla nowicjuszy przyjęcie zmian może się wydłużać, ponieważ opiekun musi zrozumieć, czy uczestnik może odpowiedzialnie podejść do swojego kodu. Dlatego uczestnicy, zwłaszcza ci próbujący wprowadzać radykalne zmiany, muszą poświęcić dużo czasu, aby stać się częścią społeczności. Na przykład, integracja zmian do budowy jądra przez kompilator Clang zajęła 10 lat.
Źródło: opennet.ru
