Open source softvér sa často opisuje v pojmoch príspevkov: kto napísal čo, ktoré patche pristáli, koľko commitov má daná osoba. Tento rámec dáva zmysel pre mnohé účely. Vynecháva však veľkú kategóriu práce, ktorá sa neobjaví v git logu a od ktorej celý systém závisí.
Niekoľko rokov som pôsobil ako Project Team Lead (PTL) pre projekty zamerané na zabezpečenie kvality v upstream komunite OpenStack. Tento titul znamenal, že som bol jedným z ľudí s prístupom na mergovanie naprieč skupinou repozitárov, zodpovedný za udržiavanie pohybu vo fronte recenzií, vedenie komunitných stretnutí a konečné rozhodovanie o tom, či je zmena pripravená na pristátie. Tu je to, ako to skutočne vyzeralo.
Čo PTL skutočne robí
Môj rozsah ako PTL pokrýval asi desať až pätnásť projektov (v zmysle GitHub repozitárov), pričom päť z nich bolo skutočne aktívnych. Byť jedným z kľúčových ľudí, ktorí mohli schvaľovať a mergovat pull requesty, znie prestížne. V praxi to znamenalo žiť vo fronte recenzií.
Môj backlog bol môj inbox. Neprečítané emailové notifikácie znamenali patch čakajúci na pozornosť: buď nový pull request, alebo existujúci, kde prispievateľ nahral novú sadu zmien. V každom danom momente som ich mal pätnásť až dvadsať. Niektoré boli priamočiare: CI úlohy zelené, zmena jasne ohraničená, rýchlo posúditeľná. Iné boli štrukturálne zmeny, ktoré trvali pol hodiny len na opätovné načítanie dostatočného kontextu na bezpečné zhodnotenie.
Raz týždenne som viedol konzultačné hodiny na IRC, otvorené pre kohokoľvek v komunite. Prispievatelia prichádzali s otázkami o patchoch, ktoré uviazli. Inžinieri z iných projektov prichádzali, keď niečo v našom testovacom frameworku rozbilo ich CI a potrebovali vedieť, či sme o tom vedeli a riešili to. Príležitostne sa objavil niekto so závislosťou: potreboval mergnutie konkrétnej zmeny, pretože ich vlastný projekt na ňom bol zablokovaný. Moja práca na týchto stretnutiach bola menej technická a viac koordinačná: zistiť, kto čo vlastní, smerovať správny problém k správnej osobe, udržiavať veci v pohybe.
Samotné recenzie boli metodické. Syntax a sémantika, samozrejme. Ale tiež: rozbíja táto zmena niečo, čo predtým fungovalo? Je v súlade so smerovaním projektu a existujúcou kódovou základňou? Odráža pokrytie testami to, čo bolo skutočne zmenené? Pre jednoduché patche s čistými výsledkami CI bola latka rýchlo splniteľná. Pre čokoľvek, čo sa dotklo štruktúry projektu, som musel pochopiť nielen to, čo kód robí, ale prečo bol pôvodný kód napísaný tak, ako bol.
Váha tlačidla merge
OpenStack beží v produkcii pre značný počet organizácií. Keď som niečo mergol, šlo to do projektov, od ktorých záviseli iné tímy, iné firmy a iné open source projekty. To nie je abstraktná zodpovednosť. Je konkrétna.
To, čo to robilo zvládnuteľným, bolo pokrytie testami. Čím viac CI úloh validovalo zmenu, tým väčšiu istotu som mal, že jej mergnutie je bezpečné. Prechod testov naprieč matricou nezaručoval, že sa nič nerozbije, ale dal vám rozumný základ pre rozhodnutie. A ak niečo predsa preniklo, mohli sme vždy rýchlo vrátiť zmenu alebo navrhnúť opravu a rýchlo ju dostať dnu.
Tiež som v žiadnom zmysluplnom zmysle nikdy nepracoval sám. Ak som si niečím nebol istý, opýtal som sa na upstream kanáli. Open source komunity (aspoň podľa mojich skúseností) sú skutočne nápomocné, keď sa obrátite priamo. A ak sa zmena dotkla časti kódovej základne, ktorej som plne nerozumel, nemergnul som ju. Označil som ju pre niekoho, kto to vedel, a požiadal ho o vyjadrenie. To môže vyzerať ako obmedzenie. Myslím, že je to správny inštinkt: rola PTL vyžaduje, aby ste boli schopní robiť rozhodnutia v neistote, ale nevyžaduje predstierať, že rozumiete veciam, ktorým nerozumiete.
Prečo dobrí správcovia vyhorievajú
Frustrácia nie je dramatická. Hromadí sa.
Recenzujete patch. Zanecháte konkrétnu, realizovateľnú spätnú väzbu. Prispievateľ sa vráti o dva týždne neskôr s novým patchsetom a vec, na ktorú ste poukázali, je stále tam, nezmenená, akoby váš komentár nikdy nebol prečítaný. Alebo sa medzera medzi vašou recenziou a jeho odpoveďou natiahne na mesiac. Vtedy je kontext, ktorý ste prvýkrát načítali, preč a musíte prejsť celou históriou patchu, aby ste dali zmysluplnú druhú recenziu. To nie je nevyhnutne vina prispievateľa. Život sa do toho pripletie. No záťaž znáša správca.
Krátke spätnoväzbové slučky záležia. Toto som si preniesol do toho, ako teraz vediem inžinierov: recenzie sa považujú za prioritnú prácu, nie za niečo, k čomu sa dostanete po všetkom ostatnom. Patch sediaci bez recenzie znamená, že sa nič nepohne ďalej. Správca čakajúci na upravený patchset má rovnaký problém naopak.
Ďalší vektor vyhorenia je kontinuita. Keď správca prejde na iný projekt alebo sa nechá vtiahnuť iným smerom, projekty, ktoré zanechá, to pocítia. Ak sa dostatok ľudí vzdiali, nakoniec máte projekt, kde nikto nedrží hlboký kontext pre určité časti kódovej základne. Patche v týchto oblastiach sa stanú ťažko recenzovateľnými nie preto, že sú zlé, ale preto, lebo nikto z tých, čo zostali, nevie s istotou povedať, či sú bezpečné.
Jedna vec, ktorá mi neprekážala, aby som to uviedol: moje meno sa neobjavuje v commit správach. Prispievateľ implementoval zmenu. Zaslúži si za to kredit. Moje recenzie a rozhodnutia o mergovaní boli sledované v Gerrite, platforme na code review, ktorú sme používali, takže práca nebola neviditeľná pre nikoho, kto sa pozrel. Ale širší bod platí: práca recenzovania, koordinácie a udržiavania málokedy dostáva rovnakú viditeľnosť ako práca budovania.
Čo by skutočne pomohlo
OpenStack je špecifický prípad. Je podporovaný veľkými firmami (Red Hat, Canonical, IBM a ďalšími), ktoré platia inžinierom za prispievanie, udržiavanie a rozvoj projektu. Tento model funguje, keď máte za sebou takú inštitucionálnu podporu.
Ale väčšina open source projektov nie je OpenStack. Ekosystém je plný malých, nenápadných projektov: JavaScript utility, Python knižnice, testovacie nástroje, malé parsery a formátovače. Mnohé z nich sú závislosťami pre tisíce iných projektov, ktoré sa zase používajú na budovanie produktov generujúcich reálne príjmy pre firmy, ktoré nikdy nevložili späť ani riadok kódu. Správcovia týchto projektov sú často jeden alebo dvaja ľudia pracujúci vo voľnom čase a nesú rovnakú záťaž recenzií, rovnakú zodpovednosť za mergovanie a rovnakú koordinačnú réžiu ako ktokoľvek iný.
Čo by pomohlo, je nejaký mechanizmus, ktorý by umožnil firmám a tímom závislým na týchto projektoch smerovať zdroje späť k práci, ktorú potrebujú urobiť. Nie dary do abstraktného fondu, ale niečo priamejšie: spôsob, ako pripojiť skutočnú hodnotu ku konkrétnym problémom, aby mali prispievatelia dôvod ich riešiť a správcovia dôvod ich uprednostniť. Motivačná štruktúra open source je momentálne asymetrická spôsobom, ktorý sťažuje tento druh udržateľnosti. Táto asymetria stojí za nápravu.