Jak velký tým se v současnosti o Bird stará?
V týmu BIRD nás je aktuálně sedm, na úvazky je to míň. Část týmu se víc zabývá vývojem a údržbou, jiní zase komunikací s uživateli, reprodukováním chyb a QA. To je nicméně interní tým, BIRD je open-source a má řadu dalších přispěvatelů, kteří se na jeho vývoji také podílejí.
Která činnost vám zabírá nejvíce času?
Posledních několik let to byl refaktoring a výkonové optimalizace, ať už kvůli vývoji BIRDa 3, nebo kvůli začleňování nových vlastností. Od vydání BIRDa 3 se to výrazně posunulo ve prospěch nových vlastností, i když samozřejmě pořád řešíme i bugy a optimalizace. Hodně jsme v posledních měsících přitlačili na QA, což souvisí i s vydáním BIRDa 3 a potřebou reprodukovat a opravovat chyby v něm.
Proč jste se před několika lety začali intenzivně zabývat rozšiřováním týmu?
Tenhle proces vlastně běžel už před deseti lety, kdy jsem nastoupila já. Tehdy jsme ale primárně sháněli seniorní, hodně schopné lidi, které nebude potřeba dlouho zaučovat. Takoví jsou na trhu opravdu vzácní, těžko se hledají a jako neziskovka ani nemáme příliš šancí kohokoliv aktivně přetáhnout z komerčního sektoru.
Takže to, co jsme udělali před několika lety, byla změna cílové skupiny. Připadalo mi rozumnější učit juniorky a juniory než čekat na Godota. Nelze se úplně spoléhat ani na příspěvky externistů, od kterých jen těžko očekávat například rozsáhlý systematický refaktoring.
Kdo je Maria Matějka?
Maria je vedoucí týmu BIRD u CZ.NIC, samu sebe označuje jako „internetovou a počítačovou čarodějnici“. O projektu BIRD a souvisejících tématech hojně prezentuje na českých i zahraničních akcích. Než před deseti lety nastoupila do CZ.NIC, pracovala u Centrum.cz a v SUSE Linux. Ve volném čase prochází opuštěné železniční tratě nebo hraje na piáno. Mariinou domovskou distribucí je už patnáct let Debian.
Proč není možné sehnat dobré hotové programátory?
Síťové projekty jako BIRD mají hodně specifickou kombinaci požadavků. Na jedné straně potřebujeme produkovat kvalitní kód v C, na druhé straně hodně do podrobna rozumíme routingu a protokolům jako BGP nebo OSPF. Přitom zrovna pokročilá síťařina je relativně vzácná sama o sobě už na uživatelské úrovni, natožpak aby někdo dokázal tyhle věci implementovat v kódu.
Odkud se dají brát junioři?
Reálně jedině rovnou ze škol. Tam se ovšem prakticky vůbec neučí routing a obvykle jsou i základy sítí takové všelijaké. To nejlepší, co najdeš, je pravděpodobně nějaký základní kurz CCNA. Nakonec se u náborů primárně orientujeme podle schopnosti programovat v C ve více vláknech, protože to je základ, bez kterého u nás budou lidi akorát trpět.
Překvapivě lidé z praxe mají nevýhodu, protože málokdo si zvládne udržet byť základy fungování počítačových sítí, když s tím běžně nedělá. Ostatně ani programování v C v userspace není běžným jevem.
Jak moc je třeba se jim věnovat?
První dva týdny po nástupu strávím (obvykle já) víc než půlku času zaučováním. Programátorská dokumentace BIRDa není úplně stavěná na juniorní vývojáře a vývojářky, takže prvních několik úkolů je vedeme krok za krokem a všechno ukazujeme, spoustu věcí je potřeba opakovat, a do rozumné samostatné produktivity se dá dorůst někde kolem devíti až dvanácti měsíců.
Juniorky a junioři se musí naučit spoustu věcí. Programování ve škole obvykle ani zdaleka nedosahuje složitosti, před kterou je postavíme. BIRD sice používá podobnou koncepci jako známé knihovny libevent nebo libuv, ale málokdo s nimi získá dostatečnou praxi. Některé části našeho kódu (třeba filtry) jsou pak navíc prakticky černá magie, na kterou i seniorní sekce týmu sahá s bázní a třesením.
THIS IS A M4 MACRO FILE GENERATING 3 FILES ALTOGETHER. KEEP YOUR HANDS OFF UNLESS YOU KNOW WHAT YOU'RE DOING. EDITING AND DEBUGGING THIS FILE MAY DAMAGE YOUR BRAIN SERIOUSLY. But you're welcome to read and edit and debug if you aren't scared.
Pak samozřejmě síťování. Základy různých protokolů, různá rozšíření a podrobné studium RFC je naším denním chlebem. Kdo se nezvládne dlouhodobě setrvale učit nebo přemýšlet o komplexních sítích, pro toho tým projektu BIRD opravdu není.
Pro seniorní sekci navíc celá práce začíná ještě před nástupem juniorů. Čím víc miniúkolů zvládneme vyselektovat v týdnech a měsících před nástupem, tím hladší je pak zaučování.
Co bývá u juniorů největší problém?
Sebedůvěra. Dnešní junioři a juniorky, a to platí pro celé IT, ani zdaleka neumí to, co uměli juniorky a junioři před dvaceti lety. Když to vedení a seniorní sekce týmu nedokáže podchytit, tak na ně nasypou na začátku příliš těžké úkoly, jejich řešení podrobí sžíravé kritice, a těžko se divit, že pak frustrovaný nedoceněný junior během tří let čtyřikrát změní práci. Já se sama snažím lidi podporovat opravdu hodně, ale taky mi někdy dojde energie nebo trpělivost a pak jsem tvrdá a zlá.
To je celé důsledkem raketového růstu IT jako oboru. Pracovní pozice přibývají tak rychle, že se obor otevřel i lidem, kteří před nástupem na VŠ nikdy neprogramovali. Mohla bych teď dlouze vyjmenovávat strukturální problémy českého školství, které za to můžou, prakticky se tomu nicméně musíme přizpůsobit.
Specificky v BIRDu to navíc hodně dlouho vypadá, že je člověk neužitečný, což dál ztěžuje adaptaci na začátku. Pokud by u nás tedy někdo chtěl dělat třeba bakalářskou nebo diplomovou práci, je vhodné ozvat se výrazně dřív než dva měsíce před odevzdáním, ať má lepší představu, do čeho jde a jak to asi bude dělat.
Proč je těžší najmout dobrého člověka na podporu než programátora?
Teoreticky by to mělo být lehčí. Nepotřebuje programování v C, stačí mu sítě. Jenomže BGP je u síťařů značně seniorní téma a těžko se ukecává zkušené adminy, aby šli dělat „na druhou stranu barikády“. Ani ve školách, jak jsem už říkala, se pořádně neučí. Na matfyzu se nicméně bude v zimním semestru 2025/26 vyučovat předmět NSWI184 Řízení počítačových sítí, který by mohl situaci trochu napravit.
Jak se u lidí z týmu vyhnout vyhoření?
Úplně vyhnout se tomu nedá, nejde ovlivnit všechno. Snažíme se aspoň o nějaký základní „projektový wellbeing“. Lidi si berou úkoly, které jim zrovna sedí, někdo preferuje dlouhé implementace, někdo refaktoring, někdo zapeklité bugy.
Zvláště důležitý je citlivý přístup ke zpětné vazbě. Kritika je nutná, bugy nemají projít. Je však potřeba hledat i to pozitivní a výslovně to říct, i když to třeba je jenom posun oproti minulému review. Demotivace dokáže přijít strašně rychle.
Nejhůř se identifikuje dlouhodobá pomalá frustrace. Tam prostě pomáhá ptát se a zajímat se, ale někdy se to stejně nashromáždí a pak člověk ze dne na den hasí požár.
Jak jde vývojářům komunikace s dalšími kolegy z firmy?
Lidsky se máme samozřejmě rádi a v nepracovní rovině mezi sebou normálně komunikujeme v míře odpovídající asocialitě každého z nás.
Pracovně by ale vždycky měl být mezi netechnickými a technickými odděleními někdo ve funkci product managera, hlavně kvůli překládání požadavků mezi korporátštinou a vývojářštinou. V případě BIRDa to je moje práce.
Jak moc přibývají novinky, které je potřeba zařazovat do Birdu?
Rychleji, než je vůbec stíháme implementovat. Většina RFC jsou sice poměrně jednoduché věci, ale čas od času přijde nějaké značně komplexní RFC, jehož implementace může trvat klidně rok. Podstatná část RFC navíc počítá primárně s implementací v komerčních routerech, které mají často zásadně odlišnou architekturu od BIRDa. Musíme tak celý koncept vždy převést do naší konfigurační struktury a rozmyslet i výkonové aspekty, aby na tom netratila naše nejsilnější uživatelská skupina – IXPs.
Rádi bychom se do budoucna dostali do pozice, kdy většinu RFC stihneme odchytnout už v procesu vzniku a napíšeme už testovací implementaci. To se nám nedávno podařilo třeba s mechanismem ASPA.
Ideální by bylo podílet se přímo na draftech autorstvím. Ovšem jen sledovat komunikaci ve více než dvaceti pracovních skupinách IETF, které jsou pro nás relevantní, by zabralo přinejmenším jeden celý úvazek, a na to teď opravdu nemáme kapacitu. Pro představu, jenom v mailing-listu pracovní skupiny IDR, která se stará o protokol BGP, mám v tuto chvíli 3588 nepřečtených zpráv a nejstarší z nich je dva roky stará.
Jaké technické novinky se chystají na nejbližší období?
Především se naše uživatelská základna může těšit na podporu EVPN v BGP, to je hodně rozsáhlý projekt, na kterém si náš nejzkušenější vývojář Ondřej Zajíček dává opravdu záležet, aby všechno běželo, jak má, a i konfigurace byla pohodlná.
Oficiální vydání už brzy čeká i agregátor prefixů, o kterém jsem mluvila letos v lednu na CSNOGu, a běží práce i na načítání MRT dumpů.
V přípravě je po 25 letech konečně API. Jeho první verzi nicméně asi vydáme až příští rok, nechceme to uspěchat.
Kolik firem platí za podporu Birdu? Je Bird výdělečný projekt?
Nabízíme vlastně tři základní kategorie služeb. Do přímé technické podpory, kterou si firmy platí paušálem, patří činnosti jako rady s běžnými provozními stavy nebo review konfigurace, ale zejména garance, že v jejich konfiguraci poběží BIRD hladce i v dalších vydaných verzích.
Zákazníkům dokážeme udělat i jednorázové školení na míru na konkrétní téma, a konečně občas za peníze vyvineme nějaké části BIRDa přednostně.
BIRD si na sebe touhle kombinací služeb vydělá. Bylo by samozřejmě hezčí, kdyby si BIRD vydělal víc, a s naším obchodním oddělením neustále ladíme naši obchodní nabídku a oslovujeme další potenciální zákazníky.
Jaký je plán řekněme na další tři roky?
Nejvíc práce padne do dalších rozšíření EVPN v BGP, obecné podpory SRv6 a API. Obecně to budou zejména vlastnosti, které v BIRDu potřebují uživatelé v datacentrech a IXP. Zkrátka nepřijdou ani milovníci našeho filtrového jazyka, který se určitě dočká několika dalších rozšíření.
V pozadí samozřejmě dál poběží vylepšování a optimalizace vícevláknového BIRDa 3. Interně máme také v plánu dál posilovat QA a zlepšovat robustnost BIRDa, včetně automatizovaného měření výkonu.
Část plánu pak zůstává otevřená – jestli se za dva roky pustíme třeba do IS-IS nebo do oficiální implementace BGPsec, to dnes nikdo netuší.
Pokud by někdo chtěl přispět patchem, stačí jej poslat do mailing-listu. Větší příspěvky doporučujeme konzultovat předem. Podrobnější informace uvádíme v pravidlech pro přispívání do projektu.
Děkuji za rozhovor.