Åpen kildekode? Ja takk!

Som utviklere finner vi ofte vårt sett med favorittverktøy som vi mener gjør jobben vår enklere og mer effektiv. Selv er jeg godt knyttet til Linux som operativsystem, Rider som IDE, Visual Studio Code som editor og AzureDevOps for oppgavehåndtering og byggagent.

Når vi treffer på mangler i våre godt kjente verktøy vegrer vi oss for å bytte til et verktøy som har denne mangelen. Vi må lære oss et nytt verktøy og hvordan vi kan bruke dette effektivt. Dette byttet er ikke alltid enkelt, og ofte oppstår savn mot det vi brukte før. Jeg fant ut av at det er ikke alltid man trenger å bytte verktøy bare fordi det har en mangel.

Hva hvis du kan selv introdusere funksjonalitet som fjerner denne mangelen?

En arbeidsdag i midten av 2020 traff vi på en av disse manglene i et verktøy vi brukte hos en tidligere arbeidsgiver, nærmere bestemt en mangel i pipeline-agentene til AzureDevOps. Problemet var ikke større enn at vi måtte skrive verdier til en fil på et spesielt format under bygging av et prosjekt. Vi forsøkte på litt forskjellige måter, men klarte ikke å finne en god løsning som vi likte – og som var gjenbrukbar i andre prosjekter.

Som de fleste andre utviklere gjør når de møter på en utfordring tok vi problemet vårt til Google. Vi var ikke de eneste som hadde møtt på denne utfordringen, men ingen hadde kommet frem til en løsning som var brukbar for oss. Under jakten på løsningen på vårt problem kom jeg over noe som senere skulle vise seg å være veldig nyttig, nemlig utviklerdokumentasjonen til AzureDevOps.

Denne dokumentasjonen tok deg igjennom hvordan utviklere selv kunne bygge utvidelser og publisere utvidelser (eller extensions som Microsoft kaller det) for andre brukere av AzureDevOps. Etter å ha lest litt på denne dokumentasjonen ble jeg nysgjerrig på om vi kunne bygge en utvidelse som ville løse problemet vårt.

Den neste tiden brukte jeg mye tid på å lese dokumentasjon, søke rundt på kode i GitHub og skrive min egen kode mens jeg prøvde å finne ut hvordan man skulle bygge en av disse utvidelsene. Det tok en del prøving og feiling, men den 9. september 2020 publiserte jeg min første utvidelse for AzureDevOps på Visual Studio Marketplace. Utvidelsen som løse de manglene vi hadde.

I skrivende stund er denne installert i 328 forskjellige AzureDevOps organisasjoner, det er vel kanskje trygt å si at dette har vært en mangel for mange andre også?

Det var en del frustrasjon i starten når jeg først startet å bygge utvidelser rundt ting som ikke ville fungere. Mangelen på dokumentasjon for enkelte deler var heller ikke til så god hjelp. Nå nesten 2 år senere har jeg bygget 4 utvidelser som ligger tilgjengelig på Marketplace. Hver av disse har løst en mangel som jeg eller noen jeg har jobbet sammen med har kommet over.

Med jevne mellomrom sjekker jeg Visual Studio Marketplace. Kanskje har noen publisert noe som løser et problem jeg ikke visste at jeg hadde? Jeg må si at jeg ble ganske så overrasket når jeg så at to av mine utvidelser hadde havnet på forsiden.

Om det man utvikler kan hjelpe bare et fåtall andre personer, gir det glede tilbake. Det viser seg at andre også setter pris på at du har brukt din tid på bygge produktet. Selv har jeg fått flere tilbakemeldinger på forskjellige utvidelser fra utviklere som takker meg for å ha laget utvidelsene og hvordan disse har hjulpet dem i deres prosjekter.

Det som gir meg mest glede er tilbakemeldinger fra brukere som foreslår endringer eller rapporter problemer som gir meg muligheten til bygge et enda bedre produkt.

Fra starten så jeg verdien av at koden til disse utvidelsene lå tilgjengelig som åpen kildekode. Det var det som gjorde at jeg klarte å utvikle min første. Jeg satte meg et mål om at koden til alle mine utvidelser også skulle ligge tilgjengelig på GitHub på et tidspunkt. Helt i mål er jeg ikke, men jobber aktivt med å oppnå dette målet.

Det er flere fordeler med at prosjekter ligger som åpen kildekode. Det åpner for andre personer kan bidra til å gjøre din kode enda bedre. Vi som utviklere har gjerne vår egen måte å tenke på og egen måte å skrive kode på. Andre utviklere kjenner kanskje til måter som kan gjøre din kode mer lesbar, gjøre den mer stabil eller bare løse et problem du selv ikke klarte å løse.

Som utviklere har mange av oss en frykt om få negative tilbakemeldinger når vi legger ut kode åpent på internett. Tilbakemeldinger om at det du gjør er feil, dårlig skrevet eller at tiden du har brukt på dette er bortkastet er aldri hyggelig. Men det er lærdom og en mulighet til å bli enda bedre.

Når man legger et prosjekt ut for andre, så stiller det også krav til deg som utvikler. Dokumentasjon må skrives som hjelper andre å komme i gang, enten det er ved å bruke det du har laget, eller dersom de ønsker å bidra til ditt prosjekt. De fleste prosjekter vil også beskrive prosesser og rutiner for de som ønsker å bidra. Det å jobbe med åpen kildekode er ikke bare å legge kode tilgjengelig for andre. Som alle andre prosjekter krever det aktivt vedlikehold og administrasjon.

Du blir kanskje overrasket når du får det første eksterne bidraget til ditt prosjekt, men det er også viktig å være kritisk – ikke alle har gode hensikter med sine bidrag. Selv om det er andre som bidrar så er det til slutt ditt navn og rykte som står bak det som kommer inn.

En mangel i et produkt betyr ikke alltid at ting stopper opp og at det er behov for å finne noe nytt. Andelen produkter som tilbyr utviklere (sluttbrukere?) å skreddersy deler av plattformen til å passe deres behov blir bare større og større.

Store organisasjoner som for eksempel Microsoft har sett gevinstene med åpne kildekode og jobber aktivt med å legge mange av sine produkter ut for at nettopp brukerne kan være med på å bestemme hvilken retning produktet skal ta. Mange prosjekter som startet som åpen kildekode har senere blitt tatt over av disse selskapene.

Selv kommer jeg til å legge mer og mer av mitt fokus på åpen kildekode og bidra mer til utviklermiljøet der jeg kan. Jeg har sett gevinsten av dette og håper at flere kan dra nytte av det jeg utvikler. Det håper jeg flere utviklere også kan bidra til. 

Kanskje du også kan utfordre din arbeidsgiver til å fokusere mot åpen kildekode der det er mulig?