Jak vznikl systém Linux? Procesy, které stojí za řízením 13 500 vývojářů

Možná jste dnes Linux používali – zejména pokud nemáte iPhone. A pokud jste dnes brouzdali po webu, je velká pravděpodobnost, že i webové stránky, které jste navštívili, obsluhoval Linux.

Linux je operační systém, ale na rozdíl od softwaru jako Microsoft Windows nebo MacOS byl Linux vyvíjen samoorganizovanou komunitou dobrovolníků.

V průběhu času se díky úsilí více než 10 000 vývojářů a vyvíjejícím se procesům pro řízení rozsahu práce jádro Linuxu rozrostlo na celkem více než 20 000 000 řádků kódu. Tvoří stabilní základ pro…

• Všechny telefony a tablety se systémem Android na planetě
• 66 % světových serverů
• 100 % z 500 největších superpočítačů

Tato technologie nevznikla díky sehranému týmu s tlustou knihou zásad a vrstvami řízení. Vzešla z několika pečlivě vybraných a kulturně zakotvených zásad a společného poslání.

V tomto příspěvku se zabývám tím, jak mohla být tak zásadní, složitá a důležitá technologie vytvořena tak efektivně bez tradiční struktury řízení. Ale nejprve…

Proč je jádro Linuxu tak působivé?“

Jádro je samotným jádrem operačního systému. Je orchestrem všech ostatních softwarových procesů v počítači nebo chytrém telefonu, rozděluje zdroje a zajišťuje komunikaci mezi hardwarem a softwarem.

Slovy G. Pascala Zacharyho lze jádro operačního systému přirovnat k „šéfovi domácího personálu, který byl tak pilný, že sloužil rodině nahoře kdykoli, ve dne v noci na zavolání, vyřizoval každý požadavek“. Jádro udržuje stroj v chodu bez ohledu na to, s čím se setká. Byl to zásadní skok ze světa, kde na počítačích mohla běžet vždy jen jedna aplikace, do světa, který známe dnes.

Jádro Linuxu, založené na UNIXu, vyvinul na počátku 90. let Linus Torvalds.

V roce 1991 Torvalds vydal první verzi – pouhých 10 000 řádků kódu – a vyvolal vzrušení v komunitě vývojářů softwaru skromným e-mailovým oznámením, které vidíte výše.

Poprvé v historii, kdy se základna uživatelů jádra rozrůstala, přispěli vývojáři svými vlastními dovednostmi v oblasti kódování a časem na testování zdarma. Pokud byli uživatelé ochotni experimentovat, mohli se pokusit dát dohromady opravu, pokud zjistili, že je něco rozbité, a diskutovat o tom, jak software vylepšit.

Jak se Eric S. Raymond zabývá ve své knize o raném open source softwaru The Cathedral and The Bazaar, vedení vývojářů jádra Linusem Torvaldsem se stalo efektivním, samoorganizujícím se a více než schopným vytvořit pravděpodobně jeden z nejsložitějších a nejpoužívanějších kusů softwaru na planetě.

V tomto článku se zabývám procesy a zásadami, které vznikly jako nezbytná podpora projektu linuxového jádra v průběhu jeho vývoje.

Jak Torvalds bez formálního procesu, jako 21letý student informatiky, dovedl projekt jádra k výšinám, kterých dosáhl…

…A co je vlastně tak těžkého na řízení vývojářů?“

Podle výzkumu společnosti Geneca více než 75 % vedoucích pracovníků v oblasti podnikání a IT věří, že jejich softwarové projekty jsou odsouzeny k neúspěchu. Obtížnost výroby spolehlivého softwaru a řízení těch, kteří jej vytvářejí, dala vzniknout bezpočtu manažerských knih, studií o produktivitě a rámců pro vedení lidí.

„Samotná složitost softwaru znamená, že není možné otestovat každou cestu,“ píše generální ředitel společnosti Kynetix Paul Smyth na serveru Finextra. „Softwarová aplikace je jako ledovec – 90 % z ní není vidět. Hlavní složitost aplikace leží pod čarou ponoru.“

Každý softwarový projekt značných rozměrů, ať už jde o CRM nebo operační systém jako Microsoft Windows, je příliš velký na to, aby se vešel do hlavy jednoho člověka. Vyžaduje sdílené znalosti a spolupráci mnoha přispěvatelů. To znamená, že vývojáři pracují na specializovaných částech aplikace a zároveň musí chápat, jak jejich práce ovlivňuje celek.

„Žádná mysl to nemůže všechno pochopit,“ poznamenal podle G. Zacharyho v knize Show stoppers! manažer týmu 250 softwarových vývojářů společnosti Microsoft, když vytvářeli operační systém od nuly, knize, která vypráví příběh týmu softwarových vývojářů Microsoftu, který v roce 1993 závodil o dokončení systému Windows NT.

Čím větší je projekt, tím pomaleji lze změny implementovat. Dokazuje to výzkum Steva McConnella, který zjistil, že u projektů nad 10 000 000 řádků se kód píše 5-10x pomaleji. Studie vývojových postupů společnosti Microsoft navíc odhalila, že na každých 1 000 řádků kódu připadá zhruba 10-20 chyb.

Přes velikost projektu a počet přispěvatelů probíhá vývoj linuxového jádra rychle a jeho velká, nadšená uživatelská základna vychytává chyby a píše záplaty, aby mohla rychle dodávat vylepšení.

V počátcích vývoje – kolem roku 1991 – nebylo neobvyklé, že Torvalds vydal více než jedno nové jádro denně. Nyní, ve vyspělejší fázi a závislé na 80 % chytrých telefonů a většině internetových serverů, je požadovaná doba vydání 8 až 12 týdnů. Při každém vydání se v jádře objeví v průměru 10 000 záplat od 2 000 vývojářů – všichni zápasí s více než 20 000 000 řádky kódu.

Jaké jsou techniky a procesy řízení potřebné k organizování této úrovně spolupráce a produktivity? No, nesepsal je vedoucí oddělení ani autor obchodní knihy. Vyvíjely se organicky, pod vedením „benevolentního diktátora“ projektu, Linuse Torvaldse.

Již v počáteční podobě na jádře Linuxu spolupracovaly stovky dobrovolníků, kteří svou práci předkládali k posouzení přímo Torvaldsovi. Jak špatně naladěný, asociální hacker řídil spory, příspěvky a komunikaci mezi tisíci vývojáři po téměř dvě desetiletí?

Jak se dokumentuje politika, procesy a 15 000 000 řádků kódu

Na rozdíl od tradiční organizace nejsou noví vývojáři jádra striktně „přijímáni“ do komunity, ale očekává se, že plně přečetli a pochopili úvodní dokumentaci. Zaměření projektu jádra na dokumentaci bylo nutností jak kvůli technické složitosti, tak kvůli obrovskému počtu vývojářů.

V repozitáři dokumentace jádra existuje množství často kladených otázek, návodů a příruček pro začátek a ještě více jich je ve wiki vytvořených a udržovaných vývojáři jádra po celém světě.

Způsob, jakým je dokumentace psána a vylepšována, odráží způsob, jakým je jádro vyvíjeno; společně, otevřeně a postupně.

Využitím očí a specializací obrovské skupiny lidí lze dokumentaci vytvářet, testovat a korigovat mnohem efektivněji, než kdyby ji vytvářel menší specializovaný tým. Abychom Linusův zákon ohnuli do podoby, které by lépe rozuměl redaktor obsahu: s dostatečným počtem očí jsou všechny překlepy zřejmé.

Kromě materiálů pro technickou podporu vytvořila komunita vývojářů jádra knihovnu procesní dokumentace, která má za úkol uhladit lidskou stránku spolupráce.

Na úvodní stránce dokumentu „Průvodce procesem vývoje jádra“ je uveden odstavec:

„Účelem tohoto dokumentu je pomoci vývojářům (a jejich manažerům) spolupracovat s vývojářskou komunitou s minimem frustrace. Je to pokus zdokumentovat, jak tato komunita pracuje, způsobem, který je přístupný těm, kteří nejsou důvěrně obeznámeni s vývojem linuxového jádra (nebo vlastně s vývojem svobodného softwaru obecně).“

Nikdo se nerodí s vrozenou znalostí systému správy verzí git nebo toho, jak odeslat patch do poštovní konference. Proto musí být vývojový proces zdokumentován – vysvětlovat stejné základní informace jednomu člověku najednou se nevyplatí!“

Jak se řídí komunikace mezi tisíci vývojáři

Konverzace mezi vývojáři probíhala otevřeně, v poštovních konferencích pro vývoj jádra. Dodnes je e-mail stále preferovaným nástrojem díky své jednoduchosti. Tyto poštovní konference byly archivovány a organizovány a tvořily soubor živé dokumentace a historie.

Vliv veřejné komunikace měl podobný efekt, jaký má dnes používání nástrojů, jako je Slack – veškeré informace jsou v bezpečí a dají se vyhledávat, místo aby se vypařily. Aby však bylo možné takovou informační palbu zvládnout, vypracoval projekt jádra komunikační politiku a distribuoval ji jako součást dokumentace.

Komunikace a spolupráce v takovém měřítku nebyla před internetem možná, takže první projekty, jako je tento, potřebovaly napsat a distribuovat rychlá a účinná řešení problémů s řízením komunity, etiketou a prezentací kódu.

Dokumentace jádra obsahuje pravidla pro zasílání oprav, takže usnadňuje ostatním kontrolu, úpravy a testování přispěného kódu. To znamená, že záplaty musí být zasílány e-mailem v prostém textu, nikoliv v příloze. Počet záplat musí být omezen na jeden e-mail a musí dodržovat specifické zásady stylu kódování:

Tato přísná standardizace je naprosto nezbytná pro tak velký projekt, jako je jádro, stejně jako pro projekty jakékoli velikosti. Pomáhá omezit chyby v prostoru, kde jediná chyba může mít vlnový efekt, který v budoucnu způsobí nestabilní kód nebo ztrátu času mnoha testerů a vývojářů.

Jak se (ne)dělají kritická rozhodnutí

Citujme Torvaldse:

„Název hry je vyhnout se nutnosti učinit rozhodnutí. Zejména pokud vám někdo řekne „vyberte si (a) nebo (b), opravdu potřebujeme, abyste o tom rozhodl“, máte jako manažer problém. Lidé, které řídíte, museli znát detaily lépe než vy, takže pokud za vámi přijdou pro technické rozhodnutí, jste v háji. Zjevně nejste kompetentní k tomu, abyste takové rozhodnutí udělali za ně.“ – Dokumentace k vývoji linuxového jádra

Kromě toho, že se projekt Linux vyhnul manažerské hierarchii, měl jasná pravidla a dokumentaci, která pomáhala přijímat rozhodnutí bez nutnosti diskuzí, debat nebo (mnoha) plamenných válek na mailing listu. Pohled do archivů vám ukáže, že ta část s flame war není vždy možná, ale co možné je, je vytvořit pravidla, která negují břemeno rozhodování.

„Klíčem k vyhnutí se velkým rozhodnutím se tak stává prosté vyhnutí se dělání věcí, které nelze vzít zpět. Nenechte se zahnat do kouta, z něhož nelze uniknout. Krysa zahnaná do kouta může být nebezpečná – manažer zahnaný do kouta je prostě k politování.“

Show Stoppers! prozrazuje, že filozofie Billa Gatese je podobná. „Obdivoval programátory a vždy je pověřoval vedením projektů, kde mohli jak řídit, tak programovat, aby se vyhnul situaci, kdy by vládu drželi profesionální manažeři buď bez programátorských zkušeností, nebo se zastaralými znalostmi“.

Jak se přispěvatelé orientují na silný společný cíl

V případě Linuxu, stejně jako je tomu u mnoha populárních open source projektů, nevzniklo jádro poté, co bylo společně navrženo velkou skupinou přispěvatelů; spíše bylo postupně vylepšováno, aniž by byla učiněna rozhodnutí, která by destabilizovala silný základ dosavadní práce. To dobře souvisí s Torvaldsovou filozofií rozhodování v oblasti řízení, ale také s filozofií zakotvenou v samotném kódu.

Linux vychází z UNIXu, což je starší operační systém navržený na základě souboru principů podobných zenu. Jak je výslovně uvedeno ve filozofii UNIXu:

„Navrhujte a vytvářejte software, dokonce i operační systémy, tak, aby byly vyzkoušeny brzy, ideálně během několika týdnů. Neváhejte zahodit neohrabané části a postavit je znovu.“

Torvalds i Raymond (který se snažil zopakovat úspěch Torvaldsova budování komunity) zjistili, že včasné a časté vydávání pomáhá shromáždit přispěvatele kolem zajímavého, rostoucího projektu, v němž vidí budoucnost. Raymond to shrnul do dvou klíčových věcí, které projekt nesmí při uvolnění do světa nesplnit:

1. Spustit
2. Přesvědčit potenciální spoluvývojáře (uživatele), že se projekt může brzy vyvinout v něco velkého

Se stejnými zásadami spouští své projekty mnoho dnešních startupů – včetně Process Street:

Nahoře je Process Street v roce 2014. Zaregistrujte si účet a podívejte se, jak daleko jsme se dostali.

Je to opakovatelný proces?“

Na první pohled vypadá náhlé spojení jednoho z nejsložitějších lidských výtvorů jako alchymie. Když však rozebereme jednotlivé složky, je snazší vidět základní proces. V době psaní knihy Katedrála a bazar Eric S. Raymond současně řídil vývoj open source e-mailového klienta. Jeho open-sourcingem se Raymond snažil zopakovat zapojení komunity a konečný úspěch projektu jádra.

Mnoho základních principů modelu Bazaar, jak jej formuloval, bude okamžitě znát každý, kdo se pohybuje ve světě startupů:

• Každé dobré softwarové dílo začíná podrbáním osobního svrbění vývojáře.
• Přistupovat k uživatelům jako ke spoluvývojářům je nejméně obtížná cesta k rychlému zlepšování kódu a efektivnímu ladění.
• Vydávejte brzy. Vydávejte často. A naslouchejte svým zákazníkům.
• Pokud máte dostatečně velkou základnu betatesterů a spoluvývojářů, téměř každý problém bude rychle charakterizován a oprava bude pro někoho zřejmá.
• Pokud se ke svým betatesterům budete chovat, jako by byli vaším nejcennějším zdrojem, odpoví vám tím, že se stanou vaším nejcennějším zdrojem.
• Další nejlepší věcí, než mít dobré nápady, je rozpoznat dobré nápady od svých uživatelů. Někdy je to druhé lepší.
• Často ta nejvýraznější a nejinovativnější řešení vznikají tak, že si uvědomíte, že vaše pojetí problému bylo špatné.
• Chcete-li vyřešit zajímavý problém, začněte tím, že najdete problém, který je zajímavý pro vás.
• Pokud má koordinátor rozvoje k dispozici komunikační médium alespoň tak dobré, jako je internet, a umí vést bez nátlaku, je mnoho hlav nevyhnutelně lepší než jedna.

Zkrátka jde o opakovatelný proces. A který byl úspěšně převzat ze světa open source do mentality startupů. Projevuje se v agilním přístupu, lean, six sigma a v postojích a politice, které si dnešní startupy vytvořily. I když se o tom často nemluví, metodika, která se vyvinula kolem prvních operačních systémů, má mnoho společného s dnešní myšlenkou iterace minimálního životaschopného produktu.