Miten Linux luotiin? Prosessit 13 500 kehittäjän johtamisen takana

Olet luultavasti käyttänyt Linuxia nykyään – varsinkin jos sinulla ei ole iPhonea. Ja jos selasit tänään nettiä, on suuri todennäköisyys, että myös vierailemasi sivuston palvelimena toimi Linux.

Linux on käyttöjärjestelmä, mutta toisin kuin Microsoftin Windowsin ja macOS:n kaltaiset ohjelmistot, Linuxin kehitti vapaaehtoisten itseorganisoitunut yhteisö.

Aikojen saatossa yli 10 000 kehittäjän ponnisteluilla ja kehittyvillä prosesseilla, joilla työn laajuutta pystytään hallitsemaan, Linuxin ydin on kasvanut kaiken kaikkiaan yli 20 000 000:een koodiriviin. Se muodostaa vakaan perustan…

• Jokainen Android-puhelin ja -tabletti planeetalla
• 66 % maailman palvelimista
• 100 % 500:sta suurimmasta supertietokoneesta

Tämä teknologia ei ole peräisin orkestroidulta tiimiltä, jolla on paksu toimintatapaohjeisto ja hallintokerroksia. Se syntyi muutamasta huolellisesti valitusta ja kulttuuriin juurtuneesta politiikasta ja yhteisestä tehtävästä.

Tässä postauksessa tarkastelen, miten näin olennainen, monimutkainen ja tärkeä teknologia voitiin tuottaa niin tehokkaasti ilman perinteistä hallintorakennetta. Mutta ensin…

Miksi Linux-ydin on niin vaikuttava?

Ydin on käyttöjärjestelmän ydin. Se on tietokoneen tai älypuhelimen kaikkien muiden ohjelmistoprosessien orkestroija, joka jakaa resurssit ja tarjoaa laitteistolle ja ohjelmistolle tavan kommunikoida.

G. Pascal Zacharyn sanoin käyttöjärjestelmän ydintä voidaan verrata ”kotitaloushenkilökunnan päällikköön, joka oli niin ahkera, että hän palveli yläkerran perhettä kaikkina hetkinä, päivin ja öin päivystäjänä, joka käsitteli jokaista pyyntöä”. Ydin pitää koneen käynnissä riippumatta siitä, mitä se kohtaa. Se oli olennainen harppaus maailmasta, jossa tietokoneet pystyivät ajamaan vain yhtä sovellusta kerrallaan, maailmaan, jonka tunnemme nykyään.

Linus Torvalds kehitti 1990-luvun alussa UNIXiin perustuvan Linux-ytimen.

Vuoteen 1991 mennessä Torvalds oli julkaissut ensimmäisen version – vain 10 000 riviä koodia – ja herätti innostusta ohjelmistokehittäjäyhteisössä yllä näkyvällä vaatimattomalla sähköposti-ilmoituksella.

Internetin yhteistoiminnallisen voiman avulla kehittäjät tarjosivat ensimmäistä kertaa historiassa omia koodaustaitojaan ja testaukseen käyttämäänsä aikaa ilmaiseksi, kun ytimen käyttäjäkunta kasvoi räjähdysmäisesti. Jos käyttäjät olivat halukkaita kokeilemaan, he saattoivat yrittää koota korjauksen, jos havaitsivat jonkin olevan rikki, ja keskustella siitä, miten ohjelmistoa voitaisiin parantaa.

Kuten Eric S. Raymond tarkastelee varhaisia avoimen lähdekoodin ohjelmistoja käsittelevässä kirjassaan The Cathedral and The Bazaar (Katedraali ja basaari), Linus Torvaldsin johtama kernelin kehittäjien joukko kasvoi tehokkaaksi, itseorganisoituvaksi ja enemmän kuin kyvykkääksi tuottamaan luultavasti yhden planeetan mutkikkaimmista ja laajimmin käytetyistä ohjelmistokokonaisuuksista.

Tässä teoksessa tarkastelen prosesseja ja toimintatapoja, jotka ovat syntyneet tarpeelliseksi tueksi Linux-ydinprojektille sen kehittyessä vuosien varrella.

Miten ilman virallisia prosesseja, 21-vuotiaana tietojenkäsittelytieteen opiskelijana, Torvalds ohjasi kernel-projektin saavuttamiinsa korkeuksiin…

…Ja mikä kehittäjien johtamisessa ylipäätään on niin vaikeaa?

Genecan tutkimuksen mukaan yli 75 prosenttia liike-elämän ja tietotekniikan johtajista uskoo, että heidän ohjelmistoprojektinsa epäonnistuvat väistämättä. Luotettavien ohjelmistojen tuottamisen ja niiden tekijöiden johtamisen vaikeus on synnyttänyt lukemattomia johtamista käsitteleviä kirjoja, tuottavuustutkimuksia ja johtamisen viitekehyksiä.

”Ohjelmistojen monimutkaisuuden vuoksi on mahdotonta testata kaikkia polkuja”, kirjoittaa Kynetixin toimitusjohtaja Paul Smyth Finextrassa. ”Ohjelmistosovellus on kuin jäävuori – 90 prosenttia siitä ei ole näkyvissä. Sovelluksen suurin monimutkaisuus on vesirajan alapuolella.”

Kaikki merkittävän kokoiset ohjelmistoprojektit, olipa kyse sitten CRM:stä tai Microsoft Windowsin kaltaisesta käyttöjärjestelmästä, ovat liian suuria mahtuakseen yhden ihmisen päähän. Se vaatii monien tekijöiden jaettua tietoa ja yhteistyötä. Tämä tarkoittaa sitä, että kehittäjät työskentelevät sovelluksen erikoistuneiden osien parissa samalla kun heidän on ymmärrettävä, miten heidän työnsä vaikuttaa kokonaisuuteen.

”Yksikään mieli ei voi käsittää kaikkea”, huomautti 250 Microsoft-ohjelmistokehittäjästä koostuneen tiimin johtaja, kun he rakensivat käyttöjärjestelmää tyhjästä, G. Zacharyn mukaan kirjassa Show stoppers! kirjassa, joka kertoo Microsoftin ohjelmistokehittäjien tiimistä, joka juoksi kilpaa saadakseen Windows NT:n valmiiksi vuonna 1993.

Mitä suurempi projekti, sitä hitaammin muutokset voidaan toteuttaa. Steve McConnellin tutkimus todistaa tämän ja havaitsi, että yli 10 000 000 rivin projekteissa koodi kirjoitetaan 5-10 kertaa hitaammin. Lisäksi Microsoftin kehityskäytäntöjä koskeva tutkimus paljasti, että jokaista tuhatta koodiriviä kohden on noin 10-20 virhettä.

Projektin koosta ja osallistujien määrästä huolimatta Linux-ytimen kehitys tapahtuu nopeasti, ja sen suuri, innostunut käyttäjäkunta löytää virheet ja kirjoittaa korjaukset, jotta parannukset saadaan nopeasti toimitettua.

Kehityksen alkuaikoina – vuoden 1991 tienoilla – ei ollut ennenkuulumatonta, että Torvalds julkisti useamman kuin yhden uuden ytimen päivässä. Nyt, kypsemmässä vaiheessa, kun 80 % älypuhelimista ja suurin osa internet-palvelimista on riippuvaisia, toivottu julkaisuaika on 8-12 viikkoa. Jokaisessa julkaisussa ytimeen tulee keskimäärin 10 000 korjausta 2 000 kehittäjältä – kaikki painivat yli 20 000 000 koodirivin kanssa.

Mitä hallintatekniikoita ja -prosesseja tarvitaan tämän tason yhteistyön ja tuottavuuden orkestroimiseen? No, niitä ei ole laatinut mikään osastopäällikkö tai liikekirjojen kirjoittaja. Ne kehittyivät orgaanisesti projektin ”hyväntahtoisen diktaattorin” Linus Torvaldsin ohjauksessa.

Linux-ytimen kehitystyötä tekivät jo alkuvaiheessa sadat vapaaehtoiset, jotka toimittivat työnsä suoraan Torvaldsille tarkistettavaksi. Miten huonotuulinen, epäsosiaalinen hakkeri onnistui lähes kahden vuosikymmenen ajan hallitsemaan tuhansien kehittäjien välisiä kiistoja, panoksia ja kommunikaatiota?

Miten politiikka, prosessit ja 15 000 000 koodiriviä dokumentoidaan

Traditionaalisesta organisaatiosta poiketen uusia ytimen kehittäjiä ei varsinaisesti ”kiinnitetä” yhteisöön, vaan odotetaan, että he ovat lukeneet ja ymmärtäneet täydellisesti perehdyttävät asiakirjat. Ydinprojektin keskittyminen dokumentointiin oli välttämätöntä sekä teknisen monimutkaisuuden että kehittäjien suuren määrän vuoksi.

Lukuisia usein kysyttyjä kysymyksiä, ohjeita ja aloitusoppaita on olemassa ytimen dokumentaatiovarastossa ja vielä enemmän wikeissä, joita ytimen kehittäjät ympäri maailmaa luovat ja ylläpitävät.

Tapa, jolla dokumentaatiota kirjoitetaan ja parannetaan, heijastaa tapaa, jolla ydintä kehitetään; yhteistoiminnallisesti, avoimesti ja vaiheittain.

Hyödyntämällä valtavan ihmisryhmän silmäpareja ja erikoisosaamista dokumentaatio voidaan luoda, testata ja oikolukea paljon tehokkaammin kuin jos sen tekisi pienempi, asialleen omistautunut ryhmä. Taivuttaakseni Linuksen lain termeihin, jotka sisällöntoimittaja ehkä ymmärtää paremmin: kun silmämunia on tarpeeksi, kaikki kirjoitusvirheet ovat ilmiselviä.

Tekniseen tukeen tarkoitetun materiaalin lisäksi ytimen kehittäjäyhteisö on luonut kirjaston prosessidokumentaatiota, joka on suunniteltu sujuvoittamaan yhteistyön inhimillistä puolta.

Kappaleen ”A guide to the Kernel Development Process” etusivulla lukee:

”Tämän dokumentin tarkoituksena on auttaa kehittäjiä (ja heidän esimiehiään) työskentelemään kehitysyhteisön kanssa mahdollisimman turhautumatta. Se on yritys dokumentoida, miten tämä yhteisö toimii tavalla, joka on helppokäyttöinen niille, jotka eivät ole läheisesti perehtyneet Linux-ytimen kehitykseen (tai itse asiassa vapaiden ohjelmistojen kehitykseen yleensä).”

Kukaan ei synny synnynnäisesti tietämään Git-versiohallintajärjestelmää tai sitä, miten lähetetään korjaustiedosto postituslistalle. Siksi kehitysprosessi on dokumentoitava – saman perustiedon selittäminen yhdelle henkilölle kerrallaan ei skaalaudu!

Miten 1000:n kehittäjän välistä viestintää hoidetaan

Kehittäjien väliset keskustelut tapahtuivat avoimesti, ytimen kehityspostituslistoilla. Vielä tänäkin päivänä sähköposti on suosituin väline sen yksinkertaisuuden vuoksi. Nämä postituslistat arkistoitiin ja järjestettiin, ja ne muodostavat elävän dokumentaation ja historian.

Julkisessa tilassa tapahtuvalla kommunikoinnilla on samankaltainen vaikutus kuin Slackin kaltaisen työkalun käyttämisen hyödyt nykyään – kaikki tieto muuttuu turvalliseksi ja hakukelpoiseksi sen sijaan, että se haihtuisi. Tällaisen informaatiotulvan hallitsemiseksi kernel-projekti kuitenkin kehitti viestintäpolitiikan ja jakoi sen osana dokumentaatiota.

Viestintä ja yhteistyö tällaisessa mittakaavassa ei ollut mahdollista ennen internetiä, joten tämän kaltaisten varhaisten projektien oli kirjoitettava ja jaettava nopeita ja tehokkaita ratkaisuja yhteisön hallintaan, etikettiin ja koodin esitystapaan liittyviin ongelmiin.

Kernelin dokumentaatiossa on myös sääntöjä korjaustiedostojen lähettämiseen, jotta muiden olisi helpompaa tarkastaa, muokata ja testata osallistuvaa koodia. Tämä tarkoittaa, että korjaukset on lähetettävä sähköpostitse pelkkänä tekstinä, ei liitteenä. Korjaukset on rajoitettava yhteen kertaan sähköpostia kohden, ja niiden on noudatettava tiettyjä koodaustyyliä koskevia ohjeita:

Tämä jäykkä standardisointi on ehdottoman välttämätöntä niinkin suurelle projektille kuin kernel, kuten se on kaiken kokoisille projekteille. Se auttaa vähentämään virheitä tilassa, jossa yksittäisellä virheellä voi olla aaltoileva vaikutus, joka tuottaa epävakaata koodia tulevaisuudessa tai tuhlaa monien testaajien ja kehittäjien aikaa.

Miten kriittisiä päätöksiä (ei) tehdä

Lainatakseni Torvaldsia:

”Pelin nimi on välttää päätöksen tekemistä. Erityisesti jos joku sanoo sinulle ”valitse (a) tai (b), tarvitsemme todella sinun päättävän tästä”, olet vaikeuksissa johtajana. Johtamiesi ihmisten on parasta tietää yksityiskohdat paremmin kuin sinä, joten jos he pyytävät sinulta teknistä päätöstä, olet pulassa. Et selvästikään ole pätevä tekemään tätä päätöstä heidän puolestaan.” – Linux-ytimen kehityksen dokumentaatio

Johtamishierarkian välttämisen lisäksi Linux-projektilla oli selkeät säännöt ja dokumentaatio, jotka auttoivat tekemään päätöksiä ilman keskustelua, väittelyä tai (monia) sähköpostilistojen liekkisotia. Vilkaisu arkistoihin osoittaa, että liekkisodan osuus ei ole aina mahdollinen, mutta mahdollista on luoda politiikka, joka mitätöi päätöksenteon taakan.

”Siten avain suurten päätösten välttämiseen tulee vain välttämään sellaisten asioiden tekemistä, joita ei voi perua. Älä ajaudu nurkkaan, josta et pääse pois. Nurkkaan ajettu rotta voi olla vaarallinen – nurkkaan ajettu johtaja on vain säälittävä.”

Show Stoppers! paljastaa, että Bill Gatesin filosofia on samanlainen. Hän ”ihaili ohjelmoijia ja laittoi heidät poikkeuksetta johtamaan projekteja, joissa he pystyivät sekä johtamaan että ohjelmoimaan, jotta vältettäisiin tilanne, jossa ammattimaiset johtajat, joilla ei ollut joko lainkaan ohjelmointikokemusta tai heidän tietämyksensä oli vanhentunutta, olisivat vallassa”.

Miten myötävaikuttajat orientoituvat vahvan yhteisen tavoitteen ympärille

Linuxin tapauksessa, kuten monien suosittujen avoimen lähdekoodin projektien kohdalla, ydin ei syntynyt sen jälkeen, kun suuri joukko myötävaikuttajia oli suunnitellut sen yhteistyössä; pikemminkin sitä parannettiin asteittain tekemättä päätöksiä, jotka horjuttivat tähänastisen työn vahvaa perustaa. Tämä sopii hyvin yhteen Torvaldsin filosofian kanssa, joka koskee päätöksentekoa hallinnossa, mutta myös itse koodiin upotetun filosofian kanssa.

Linux perustuu UNIXiin, joka on aiempi käyttöjärjestelmä, joka on suunniteltu zenin kaltaisten periaatteiden pohjalta. Kuten UNIX-filosofiassa nimenomaisesti sanotaan:

”Suunnittele ja rakenna ohjelmistot, jopa käyttöjärjestelmät, siten, että niitä voidaan kokeilla varhaisessa vaiheessa, mieluiten viikkojen kuluessa. Älä epäröi heittää kömpelöitä osia pois ja rakentaa ne uudelleen.”

Kumpikin Torvalds ja Raymond (jotka pyrkivät jäljittelemään Torvaldsin menestyksekästä yhteisörakentamista) havaitsivat, että varhainen ja usein tapahtuva julkaiseminen auttoi keräämään osallistujat jännittävän, kasvavan projektin ympärille, jossa he näkevät tulevaisuuden. Raymond kiteytti asian kahteen keskeiseen asiaan, joita projekti ei voi jättää tekemättä, kun se julkaistaan maailmaan:

1. Käynnistää
2. Vakuuttaa potentiaaliset kanssakehittäjät (käyttäjät) siitä, että projektista voidaan pian kehittää jotakin suurta

Näillä samoilla periaatteilla monet nykypäivän startup-yritykset käynnistävät projektin – Process Street mukaan luettuna:

Yllä on Process Street vuonna 2014. Rekisteröidy tilille nähdäksesi, miten pitkälle olemme päässeet.

Onko tämä toistettavissa oleva prosessi?

Pinnalta katsottuna yhden ihmisen monimutkaisimmista luomuksista yhtäkkinen yhteen tuleminen vaikuttaa alkemialta. Mutta erittelemällä osatekijöitä on helpompi nähdä taustalla oleva prosessi. The Cathedral and The Bazaarin kirjoittamisen aikaan Eric S. Raymond johti samanaikaisesti avoimen lähdekoodin sähköpostiohjelman kehittämistä. Avoimen lähdekoodin avulla Raymond yritti toistaa kernel-projektin yhteisöllisen osallistumisen ja lopullisen menestyksen.

Monet Bazaar-mallin, kuten hän sen keksi, perusperiaatteet ovat välittömästi tuttuja kenelle tahansa startup-maailmassa toimivalle:

• Kaikkien hyvien ohjelmistojen lähtökohtana on, että ne raapivat kehittäjän henkilökohtaista kutinaa.
• Käyttäjien kohteleminen kanssakehittäjinä on vaivattomin tie nopeaan koodin parantamiseen ja tehokkaaseen virheenkorjaukseen.
• Julkaise aikaisin. Julkaise usein. Ja kuuntele asiakkaitasi.
• Jos sinulla on tarpeeksi suuri joukko beta-testaajia ja yhteiskehittäjiä, melkein jokainen ongelma luonnehditaan nopeasti ja korjaus on jollekulle ilmeinen.
• Jos kohtelet beta-testaajiasi ikään kuin he olisivat arvokkain resurssisi, he vastaavat siihen muuttumalla arvokkaimmaksi resurssiksesi.
• Hyvien ideoiden saamisen jälkeen seuraavaksi parasta on tunnistaa hyvien ideoiden saaminen käyttäjiltäsi. Joskus jälkimmäinen on parempi.
• Usein hätkähdyttävimmät ja innovatiivisimmat ratkaisut syntyvät siitä, että tajuat, että käsityksesi ongelmasta oli väärä.
• Ratkaistaksesi mielenkiintoisen ongelman, aloita etsimällä ongelma, joka kiinnostaa sinua.
• Edellyttäen, että kehittämiskoordinaattorilla on vähintään yhtä hyvä viestintäväline kuin internet ja että hän osaa johtaa ilman pakottamista, monta päätä on väistämättä parempi kuin yksi.

Lyhyesti sanottuna kyseessä on toistettava prosessi. Ja sellainen, joka on onnistuneesti omaksuttu avoimen lähdekoodin maailmasta startup-mentaliteettiin. Se ilmenee ketteränä, leanina, six sigmana sekä asenteina ja toimintatapoina, joita startupit ovat nykyään kehittäneet. Vaikka sitä ei useinkaan mainita samassa keskustelussa, varhaisten käyttöjärjestelmien ympärille kehittyneellä metodologialla on paljon yhteistä tämän päivän ajatuksen kanssa, joka koskee pienimmän elinkelpoisen tuotteen iterointia.