Open source osana projektia


2014-11-17, 11:15 Kirjoittanut Ilkka Tengvall

Hei,

jatkan aiemmin aloittamaani "Voita avaamalla oikein" kirjoitusta kertomalla kuinka ulkoinen open source otetaan onnistuneesti huomioon projekteissa osana tuotteistusta. On tärkeää ymmärtää open source toimintamalli ja kuinka "upstream":in, eli avoimen lähdekoodin alkuperäisen julkaisijan kanssa on toimittava.

Upstream tarkoittaa avoimen lähdekoodin projektia jota ylläpitää yhteisö tai yksittäinen kehittäjä.

 

(kuvaaja: Jussi Aalto)

 

Muutokset minimiin, aikataulujen ristiriita

Jotta tavoitamme maksimaalisen hyödyn avoimesta lähdekoodista, omat muutokset siihen on pidettävä minimissä. Joko käytät koodia osana tuotettasi em. kolmion "yleiset ohjelmistot" hyödykeosassa muuttamatta sitä, tai aktiivisesti julkaiset koodimuutoksesi upstreamiin osaksi alkuperäistä tuotetta.

Avoimen koodin julkaisemisessa on oma prosessinsa, joka ei todennäköisesti noudata projektiaikatauluasi. Alkuperäinen upstream elää omaa aikatauluaan, etkä yleensä pääse vaikuttamaan sen aikatauluun, ellet omista alkuperäistä projektia. Voi olla että projektisi kestää esim. kaksi kuukautta, mutta upstream projektin julkaisuväli on esim. puoli vuotta. On olemassa riski, että julkaisemasi koodit eivät menekkään tahtosi mukaan alkuperäiseen projektiin, ja oma projektisi voikin olla jo ohi kun muutoksilla olisi mahdollisuus päästä upstreamiin. Jäät yksin ylläpitämään omaa versiotasi koodista, ja se maksaa ajan kuluessa. Tämä riski vältetään ottamalla open source työtavat huomioon projektia suunniteltaessa.

Julkaise usein, julkaise vähän

Ole avoin työstäsi. Projektin alussa on hyvä varata hetki aikaa esitellä tulevat muutokset upstreamille. Näin saat heti alkuun arvokasta vinkkiä onko muutoksillasi mahdollisuutta päästä osaksi alkuperäistä tuotetta. Tässä kohtaa on mahdollista saada etua upstreamin yhteisöstä, jolta voi saada rakentavaa kritiikkiä ja ohjeistusta kuinka muutosta voisi tehdä jopa paremmin. Mahdollisesti löydät jonkun joka olisi jo tehnyt suunnitelmaa samankaltaisesta muutoksesta, ja pääset omasta osuudestasi helpommalla jakamalla työtä.

 

Pienissä hipuissa julkaisu on myös kevyempää upstreamille, joka ymmärtää helpommin ja saa nopeasti arvioitua muutostesi laadun ja toiminnan. Tämä on tärkeä osa muutosten ottamista osaksi upstreamia. Ota projektisi osaksi esimerkiksi sprinttien tahtinen julkaisu, tai joku muu lyhyt aika. Kommunikoi upstreamiin selkeästi miksi ja miten muutokset on tehty.

Ole reaktiivinen

Muista olla kiitollinen saamastasi ilmaisesta työstä minkä saat yhteisöltä. Ensimmäinen tapa on olla kohtelias, ja vastata mahdollisimman välittömästi mahdollisiin kysymyksiin, ehdotuksiin tai kritiikkiin koodistasi. Näin osoitat arvostusta, etkä ole tungetteleva öykkäri :)

Hännät haltuun

Projektisi voi olla päättynyt, mutta koodisi luovuttaminen upstreamiin on vielä kesken. Tämä täytyy ottaa huomioon aikataulutuksessa. Kuka hoitaa homman loppuun? Projektiisi on hyvä laskea aikaa hännille, jossa kommunikodaan upstreamin kehittäjien kanssa koodin luovutuksen loppuun saakka. Varaa esim. yksi projektin jäsen pienellä työpanoksella tekemään satunnaista kommunikointia. Seuraamaan bugiraportteja, ottamaan vastaan muutoksia, yms.

Tässä oli pientä vihjettä kuinka rakennat voittavaa open-source tuoteprojektia. Näillä vinkeillä pääset alkuun kuinka saat ylläpidettävämmän tuotteen, ja säästät rahaa tulevasta ylläpidosta. Ehkäpä koodarikin innostuu osaksi yhteisöä, ja saa lisämaustetta ja arvostusta työhönsä! Ota yhteyttä jos kaipaat apua open source projekteissasi.

Ai niin, miksi Kekkosen kuva? No koska, tämä kuva selittää.... :)

Ilkka Tengvall

ilkka.tengvall@cybercom.com


comments powered by Disqus