Milloin basaari toimii

Tämän kirjoituksen luonnosvaiheen lukijat ja koeyleisöt kysyivät, millaisissa oloissa basaarityylinen ohjelmistokehitys voi toimia. He pohtivat työn vetäjän pätevyysvaatimuksia ja sitä, missä ohjelmistokehityksen vaiheessa ohjelman lähdekoodin voi julkaista ja kehittäjien yhteisöä voi käydä rakentamaan.

On varsin ilmeistä, että ohjelmiston kehitystä ei voi aloittaa aivan nollapisteestä basaarityylillä [IN]. Tyyli sopii ohjelmiston testaukseen, virheiden korjaamiseen ja paranteluun, mutta sillä olisi vaikeaa polkaista kehityshanketta käyntiin. Linus ei yrittänyt sitä, enkä minäkään. Orastava kehittäjäyhteisö tarvitsee lähtökohdaksi ajokelpoisen ohjelman, jota voi testata ja jolla voi leikkiä.

Alkuvaiheessa osallistujille on pystyttävä antamaan lupaava vaikutelma. Ohjelman ei vielä tarvitse toimia erityisen hyvin. Se voi olla vielä karkea, siinä voi olla virheitä, ja se voi olla keskeneräinen ja puutteellisesti dokumentoitu. Kuitenkin sen on (a) oltava ajettavissa ja (b) saatava yhteistyökumppanit uskomaan, että tulossa on jotain todella hienoa.

Kun Linuxin ja Fetchmailin ensimmäiset versiot julkaistiin, kummankin perusrakenne oli vahva ja kiinnostava. Tätä onkin pidetty aivan oikein ensiarvoisen tärkeänä hankkeiden onnistumiselle, kun on pohdittu basaarimallin hyödyntämistä. On kuitenkin hätäistä vetää sellaista johtopäätöstä, että kehitystyön vetäjältä vaaditaan huippuluokan intuitiota ja älyä.

On muistettava, että Linus käytti hyväkseen Unixin perusrakennetta. Itse tukeuduin varhaiseen POP-asiakasohjelmaan, joka tosin koki sitten suhteellisesti suurempia muodonmuutoksia kuin Linux. Onko basaarityylillä toteutetun hankkeen vetäjän tai koordinaattorin oltava erityisen lahjakas ohjelmistosuunnittelija, vai voiko hanke onnistua muiden osallistujien taitojen varassa?

Mielestäni olennaista ei ole se, että koordinaattori pystyy itse häikäisevään ohjelmistosuunnitteluun, vaan se että hän pystyy arvioimaan, mitkä toisten tuottamista ideoista ovat hyviä.

Tätä väitettä voidaan perustella sekä Linux- että Fetchmail-projektilla. Kuten sanottua, Linus ei ole ollut huikean omintakeinen ohjelmistosuunnittelijana, mutta hänellä on ollut armoitettu kyky tunnistaa hyviä suunnitteluideoita ja hyödyntää niitä Linuxin ytimessä. Vastaavasti Fetchmailin tärkein idea, SMTP-välitys, ei ollut minun keksintöni.

Tämän esseen luonnosvaiheen lukijat arvelivat kohteliaasti, että saatan aliarvioida basaarimallin ohjelmistosuunnittelun omintakeisuutta, koska olen itse omintakeinen ja otan sen itsestäänselvyytenä. Siinä voi olla perää, koska ohjelmistosuunnittelu on varmasti vahvin puoleni, toisin kuin ohjelmointi ja virheiden korjaaminen.

Nokkelassa ja luovassa ohjelmistosuunnittelussa on se ongelma, että siitä voi tulla tapa. Asiaa ajattelematta alkaa hakea silmää viehättäviä ja monimutkaisia ratkaisuja silloinkin, kun pitäisi tavoitella vakautta ja yksinkertaisuutta. Joitakin omia projektejani on kaatunut siihen, että olen tehnyt tällaisen virheen, mutta Fetchmailin kehityksessä onnistuin välttämään sen.

Fetchmail taisi onnistua osaksi sen ansiosta, että en sortunut viisasteluun. Voi siis sanoa, että ohjelmistosuunnittelun omaperäisyys ei ole välttämätöntä basaarimallissa. Ajatellaanpa vaikka, miten olisi käynyt jos Linus Torvalds olisi kehitystyössään yrittänyt luoda perustavaa laatua olevia käyttöjärjestelmäsuunnittelun innovaatioita. Tuskinpa meillä silloin olisi nykyisen kaltaista vakaata, laajaan käyttöön levinnyttä ydintä.

Totta kai tarvitaan jonkinlainen perustason tietämys ohjelmistosuunnittelusta ja ohjelmoinnista. Jokainen joka harkitsee basaarityylin kehityshankkeen käynnistämistä, on luultavasti kuitenkin edistynyt jo paljon pidemmälle. Avoimen lähdekoodin yhteisössä toimivat maineen sisämarkkinat ohjaavat varomaan sellaisten hankkeiden lanseeraamista, joiden loppuun saattamiseen omat kyvyt eivät riitäkään. Toistaiseksi tämä näyttää toimineen hyvin.

On kuitenkin taitoja, joita ei tavallisesti liitetä ohjelmistosuunnitteluun ja jotka ovat basaariprojekteissa mielestäni yhtä tärkeitä tai ehkä tärkeämpiäkin kuin suunnitteluäly. Basaariprojektin koordinaattorilla tai vetäjällä on oltava hyvät ihmissuhde- ja viestintätaidot.

Senhän pitäisi olla itsestään selvää. Jotta voi muodostaa kehittäjäyhteisön, on vedettävä mukaan ihmisiä, herätettävä heidän mielenkiintonsa ja pidettävä heidät tyytyväisinä työn määrään. Tekniikan uudistamisessa syntyvä kuhina auttaa paljon, mutta se ei riitä. Projektin vetäjän itsestään antama vaikutelma on tärkeää sekin.

Ei ole mikään sattuma, että Linus on mukava heppu, joka saa muut pitämään itsestään ja tarjoamaan apua. Eikä ole sattumaa, että itse olen energinen ekstrovertti; minusta on mukavaa innostaa joukkoja, ja siinä auttavat synnynnäisen lavakoomikon vaistot. Basaarityylin työnjohdossa on suurta etua, jos osaa edes vähän hurmata ihmisiä.