Hogyan jött létre a Linux? A 13 500 fejlesztő irányítása mögötti folyamatok

Vélhetően ma már Ön is használt Linuxot – különösen, ha nincs iPhone-ja. És ha ma böngészett a weben, nagy az esélye, hogy a meglátogatott weboldalt is Linux szolgáltatta.

A Linux egy operációs rendszer, de az olyan szoftverekkel ellentétben, mint a Microsoft Windows és a macOS, a Linuxot önkéntesek önszerveződő közössége fejlesztette.

Az idők során több mint 10 000 fejlesztő erőfeszítésével és a munka terjedelmét kezelő, fejlődő folyamatokkal a Linux kernel összesen több mint 20 000 000 kódsorra nőtt. Ez képezi a stabil alapját…

• A világ összes Android telefonjának és táblagépének
• a világ szervereinek 66%-a
• az 500 legjobb szuperszámítógép 100%-a

Ez a technológia nem egy vastag szabálykönyvvel és vezetési rétegekkel rendelkező, összehangolt csapattól származik. Ez néhány gondosan kiválasztott és kulturálisan beágyazott irányelvből és egy közös küldetésből jött létre.

Ebben a bejegyzésben azt vizsgálom, hogy egy ilyen alapvető, összetett és fontos technológiát hogyan lehetett ilyen hatékonyan létrehozni hagyományos irányítási struktúra nélkül. De előbb…

Miért olyan lenyűgöző a Linux kernel?

A kernel az operációs rendszer magja. Ez a számítógép vagy okostelefon összes többi szoftverfolyamatának irányítója, amely felosztja az erőforrásokat, és biztosítja a hardver és a szoftver kommunikációjának módját.

G. Pascal Zachary szavaival élve egy operációs rendszer kernelét “a háztartási személyzet főnökéhez lehet hasonlítani, aki olyan szorgalmas, hogy minden pillanatban, éjjel és nappal ügyeletben, minden kérést kiszolgálva kiszolgálja a családot odafent”. A kernel tartja működésben a gépet, bármivel is kerüljön szembe. Lényeges ugrást jelentett abból a világból, ahol a számítógépek egyszerre csak egy alkalmazást tudtak futtatni, a ma ismert világba.

A Linux kernelt, amely a UNIX-on alapul, Linus Torvalds fejlesztette ki az 1990-es évek elején.

1991-re Torvalds kiadta az első verziót – mindössze 10 000 sornyi kódot -, és a fent látható szerény email-bejelentéssel izgalmat keltett a szoftverfejlesztő közösségben.

Az internet együttműködő erejének köszönhetően a történelemben először a fejlesztők ingyenesen adták hozzá saját kódolási tudásukat és tesztelési idejüket, miközben a kernel felhasználói bázisa robbanásszerűen megnőtt. Ha hajlandóak voltak kísérletezni, a felhasználók megpróbálhattak összedobni egy javítást, ha úgy találták, hogy valami elromlott, és megvitathatták, hogyan lehetne javítani a szoftvert.

Amint Eric S. Raymond a korai nyílt forráskódú szoftverekről szóló könyvében, a The Cathedral and The Bazaar-ban vizsgálja, Linus Torvalds irányítása alatt a kernel fejlesztői hatékony, önszerveződő és több mint alkalmasnak bizonyult arra, hogy a világ vitathatatlanul egyik legösszetettebb és legszélesebb körben használt szoftverét létrehozza.

Ebben a cikkben azokat a folyamatokat és irányelveket vizsgálom, amelyek a Linux kernel projekt szükséges támogatásaként alakultak ki, ahogy az évek során fejlődött.

Hogyan, hivatalos folyamatok nélkül, 21 éves informatikus hallgatóként hogyan vezette Torvalds a kernel projektet olyan magasságokba, amilyen magasra jutott…

…És egyáltalán, mi olyan nehéz a fejlesztők irányításában?

A Geneca kutatása szerint az üzleti és informatikai vezetők több mint 75%-a úgy véli, hogy a szoftverprojektek kudarcra vannak ítélve. A megbízható szoftverek előállításának és a fejlesztők irányításának nehézségei számtalan menedzsmentkönyvet, termelékenységi tanulmányt és vezetési keretrendszert eredményeztek.

“A szoftverek puszta komplexitása azt jelenti, hogy lehetetlen minden utat tesztelni” – írja Paul Smyth, a Kynetix vezérigazgatója a Finextrán. “Egy szoftveralkalmazás olyan, mint egy jéghegy – 90%-a nem látható. Az alkalmazás legnagyobb komplexitása a vízvonal alatt rejlik.”

Minden jelentős méretű szoftverprojekt, legyen az egy CRM vagy egy operációs rendszer, mint a Microsoft Windows, túl nagy ahhoz, hogy egyetlen ember fejében elférjen. Sok közreműködő közös tudására és együttműködésére van szükség. Ez azt jelenti, hogy a fejlesztők az alkalmazás speciális részein dolgoznak, miközben meg kell érteniük, hogy munkájuk hogyan hat az egészre.”

“Egyetlen elme sem képes mindent felfogni” – jegyezte meg egy 250 Microsoft szoftverfejlesztőből álló csapat vezetője, miközben a semmiből építettek egy operációs rendszert, G. Zachary szerint a Show stoppers! könyvében, amely a Microsoft szoftverfejlesztő csapatának történetét meséli el, akik a Windows NT befejezéséért versenyeztek 1993-ban.

Minél nagyobb a projekt, annál lassabban lehet végrehajtani a változtatásokat. Steve McConnell kutatása bizonyítja ezt, amely szerint a 10 000 000 sor feletti projekteknél 5-10x lassabban íródik a kód. Továbbá a Microsoft fejlesztési gyakorlatának tanulmányozása során kiderült, hogy 1000 sornyi kódra nagyjából 10-20 hiba jut.

A projekt mérete és a közreműködők száma ellenére a Linux kernel fejlesztése gyorsan történik, és a nagyszámú, lelkes felhasználóközönség észreveszi a hibákat, és javításokat ír, hogy gyorsan szállítsák a fejlesztéseket.

A fejlesztés korai időszakában – 1991 körül – nem volt szokatlan, hogy Torvalds naponta több mint egy új kernelt adott ki. Most, az érettebb szakaszban, amikor az okostelefonok 80%-a és az internetes szerverek többsége függ tőle, a kívánt kiadási időszak 8-12 hét. Minden egyes kiadásnál a kernelhez átlagosan 10 000 javítás érkezik 2000 fejlesztőtől – mindannyian több mint 20 000 000 kódsorral birkóznak.

Milyen irányítási technikák és folyamatok szükségesek az ilyen szintű együttműködés és termelékenység megszervezéséhez? Nos, ezeket nem egy osztályvezető vagy üzleti könyvek szerzője írta ki. Szervesen fejlődtek, a projekt “jóindulatú diktátorának”, Linus Torvaldsnak az irányításával.

A Linux kernelen már születő formájában is önkéntesek százai dolgoztak együtt, akik munkájukat közvetlenül Torvaldsnak küldték el felülvizsgálatra. Hogyan irányította egy rosszkedvű, antiszociális hacker a vitákat, a hozzájárulásokat és a több ezer fejlesztő közötti kommunikációt közel két évtizeden keresztül?

Hogyan dokumentálják a szabályzatot, a folyamatokat és a 15 000 000 sornyi kódot

A hagyományos szervezetekkel ellentétben az új kernelfejlesztőket nem szigorúan “beszállítják” a közösségbe, hanem elvárják, hogy teljesen elolvassák és megértsék a bevezető dokumentációt. A kernel projekt dokumentációra való összpontosítása szükségszerű volt mind a technikai összetettsége, mind a fejlesztők száma miatt.

A kernel dokumentációs tárában számtalan GYIK, útmutató és kezdeti útmutató található, és még több a kernel fejlesztői által világszerte létrehozott és karbantartott wikikben.

A dokumentáció megírásának és javításának módja tükrözi a kernel fejlesztésének módját; együttműködésben, nyíltan és fokozatosan.

Az emberek hatalmas csoportjának szemfülességét és szakértelmét kihasználva a dokumentáció sokkal hatékonyabban készíthető, tesztelhető és lektorálható, mintha egy kisebb, elkötelezett csapat végezné. Linus törvényét egy tartalomszerkesztő által talán jobban érthető kifejezésekre hajlítva: elegendő szemfülességgel minden elgépelés nyilvánvaló.

A technikai támogatásra szánt anyagok mellett a kernelfejlesztő közösség egy olyan folyamatdokumentációs könyvtárat hozott létre, amely az együttműködés emberi oldalát hivatott elsimítani.

A “A guide to the Kernel Development Process” című dokumentum indexoldalán egy bekezdés így szól:

“Ennek a dokumentumnak az a célja, hogy a fejlesztők (és vezetőik) a lehető legkevesebb frusztrációval dolgozhassanak együtt a fejlesztői közösséggel. Ez egy kísérlet arra, hogy dokumentálja, hogyan működik ez a közösség, olyan módon, hogy azok számára is hozzáférhető legyen, akik nem ismerik alaposan a Linux kernel fejlesztését (vagy általában a szabad szoftverek fejlesztését).”

Senki sem születik úgy, hogy veleszületett tudással rendelkezik a git verziókezelő rendszerről, vagy arról, hogyan kell egy javítást elküldeni egy levelezőlistára. Ezért kell a fejlesztési folyamatot dokumentálni – ugyanazt az alapvető információt egyszerre egy embernek elmagyarázni nem skálázható!

Hogyan történik a kommunikáció 1000 fejlesztő között

A fejlesztők közötti beszélgetések a szabadban, a kernel fejlesztői levelezőlistákon történtek. A mai napig az e-mail a legkedveltebb eszköz az egyszerűsége miatt. Ezeket a levelezési listákat archiválták és rendszerezték, így egy élő dokumentációt és történelmet alkotva.

A nyilvános kommunikációnak hasonló hatása van, mint ma egy olyan eszköz használatának előnyei, mint a Slack – minden információ biztonságossá és kereshetővé válik, ahelyett, hogy elpárologna. Egy ilyen információ-tűzcső kezelésére azonban a kernel projekt kommunikációs szabályzatot dolgozott ki, és azt a dokumentáció részeként terjesztette.

Az ilyen mértékű kommunikáció és együttműködés az internet előtt nem volt lehetséges, ezért az ehhez hasonló korai projekteknek gyors és hatékony megoldásokat kellett írniuk és terjeszteniük a közösségkezelés, az etikett és a kódbemutatás problémáira.

A kernel dokumentációja tartalmazza a javítások benyújtásának szabályait, így megkönnyíti mások számára a hozzájáruló kód felülvizsgálatát, szerkesztését és tesztelését. Ez azt jelenti, hogy a javításokat egyszerű szövegben kell elküldeni e-mailben, nem csatolva. A javításokat e-mailenként legfeljebb egyszer kell elküldeni, és meghatározott kódolási stílusirányelveknek kell megfelelniük:

Ez a merev szabványosítás feltétlenül szükséges egy olyan nagy projekt esetében, mint a kernel, ahogyan bármilyen méretű projekt esetében. Segít csökkenteni a hibák számát egy olyan térben, ahol egyetlen hiba olyan hullámhatással járhat, amely a jövőben instabil kódot eredményez, vagy sok tesztelő és fejlesztő idejét pazarolja.

Hogyan (nem) születnek a kritikus döntések

Torvaldsot idézve:

“A játék neve az, hogy ne kelljen döntést hozni. Különösen, ha valaki azt mondja neked, hogy “válassz (a) vagy (b), nagyon szeretnénk, ha döntenél erről”, akkor vezetőként bajban vagy. Az általad irányított embereknek jobb, ha jobban ismerik a részleteket, mint te, így ha hozzád fordulnak egy technikai döntésért, neked annyi. Egyértelműen nem vagy kompetens arra, hogy ezt a döntést helyettük meghozd”. – Linux Kernel fejlesztési dokumentáció

A vezetői hierarchia elkerülése mellett a Linux projektnek világos szabályai és dokumentációja volt, amelyek segítették a döntések meghozatalát, viták, viták és (sok) levelezőlistás lángháborúk nélkül. Egy pillantás az archívumokra megmutatja, hogy a lángháború része nem mindig lehetséges, de ami lehetséges, az az, hogy olyan szabályzatot hozzunk létre, amely negligálja a döntés terhét.

“Így a nagy döntések elkerülésének kulcsa az lesz, hogy egyszerűen elkerüljük, hogy olyan dolgokat tegyünk, amelyeket nem lehet visszacsinálni. Ne szorítsuk magunkat olyan sarokba, ahonnan nem tudunk kiszabadulni. Egy sarokba szorított patkány veszélyes lehet – egy sarokba szorított menedzser csak szánalmas.”

A Bill Gates filozófiája is hasonló, derül ki a Show Stoppers! “Csodálta a programozókat, és kivétel nélkül őket bízta meg olyan projektek vezetésével, ahol egyszerre tudtak menedzselni és programozni, hogy elkerülje azt a helyzetet, amelyben a programozási tapasztalattal nem rendelkező vagy elavult tudású hivatásos menedzserek uralkodnak”.

Hogy a közreműködők egy erős közös cél körül orientálódnak

A Linux esetében, mint sok népszerű nyílt forráskódú projekt esetében, a kernel nem úgy alakult ki, hogy a közreműködők nagy csoportja közösen tervezte; inkább fokozatosan fejlesztették tovább anélkül, hogy olyan döntéseket hoztak volna, amelyek destabilizálják az eddigi munka erős alapját. Ez jól illeszkedik Torvalds filozófiájához a döntéshozatalról a vezetésben, de magába a kódba beágyazott filozófiához is.

A Linux alapja a UNIX, amely egy korábbi operációs rendszer, amelyet egy sor zen-szerű elv köré terveztek. Ahogyan az a UNIX filozófiájában kifejezetten szerepel:

“A szoftvereket, még az operációs rendszereket is úgy tervezzük és építjük, hogy korán, ideális esetben heteken belül ki lehessen próbálni. Ne habozz, hogy eldobd az ügyetlen részeket, és újjáépítsd őket.”

Mind Torvalds, mind Raymond (aki Torvalds közösségépítési sikerét igyekezett megismételni) úgy találta, hogy a korai és gyakori kiadás segített a közreműködőket egy izgalmas, növekvő projekt köré gyűjteni, amelyben látják a jövőt. Raymond ezt két kulcsfontosságú dologra vezette vissza, amit egy projektnek nem lehet nem teljesítenie, amikor a világra bocsátják:

1. Futtatni
2. Meggyőzni a potenciális társfejlesztőket (felhasználókat), hogy a projektből hamarosan valami nagyszerűt lehet fejleszteni

Ezekkel az elvekkel indul el sok mai startup – köztük a Process Street is:

Fentebb a Process Street 2014-ben. Regisztráljon egy fiókot, hogy lássa, milyen messzire jutottunk.

Ez egy megismételhető folyamat?

A felszínen az egyik legbonyolultabb emberi alkotás hirtelen összeállása alkímiának tűnik. De, ha szétszedjük az alkotóelemeket, könnyebb meglátni egy mögöttes folyamatot. A The Cathedral and The Bazaar megírásának idején Eric S. Raymond egyidejűleg egy nyílt forráskódú e-mail kliens fejlesztésével foglalkozott. A nyílt forráskóddal Raymond megpróbálta megismételni a kernel-projekt közösségi részvételét és végső sikerét.

A Bazár-modell számos alaptétele, ahogy ő fogalmazta meg, azonnal ismerős lesz bárki számára a startupok világából:

• Minden jó szoftver a fejlesztő személyes viszketésének megvakarásával kezdődik.
• A felhasználók társfejlesztőként való kezelése a legkevesebb gondot okozó út a gyors kódfejlesztéshez és a hatékony hibakereséshez.
• Forráskor kiadni. Adj ki gyakran. És hallgassa meg az ügyfeleit.
• Egy elég nagy béta-tesztelő és társfejlesztői bázis esetén szinte minden probléma gyorsan jellemezhető, és a megoldás nyilvánvaló lesz valaki számára.
• Ha úgy kezeli a béta-tesztelőit, mintha ők lennének a legértékesebb erőforrásai, ők válaszul a legértékesebb erőforrásává válnak.
• A jó ötletek mellett a legjobb dolog a felhasználók jó ötleteinek felismerése. Néha az utóbbi jobb.
• A legmeglepőbb és leginnovatívabb megoldások gyakran abból származnak, hogy rájössz, hogy a problémáról alkotott elképzelésed rossz volt.
• Az érdekes probléma megoldásához kezdd azzal, hogy találsz egy számodra érdekes problémát.
• Feltéve, hogy a fejlesztési koordinátor legalább olyan jó kommunikációs eszközzel rendelkezik, mint az internet, és tudja, hogyan kell kényszerítés nélkül vezetni, a sok fej elkerülhetetlenül jobb, mint az egy.

Röviden, ez egy megismételhető folyamat. És egy olyan, amelyet sikeresen átvettek a nyílt forráskód világából a startup mentalitásba. Ez manifesztálódik az agilis, a lean, a hat szigma, valamint a mai startupok által kialakított hozzáállásban és politikában. Bár nem gyakran említik ugyanabban a beszélgetésben, a korai operációs rendszerek körül kialakult módszertan sok közös vonása van a minimálisan életképes termék iterációjának mai elképzelésével.