Blogindlæg af Jesper Hauge, Head of Development, Novicell

Det er et stykke tid siden IT-verdenen nåede forbi diskussionen om Open Source software kan være levedygtigt og værdifuldt, også i offentlige og kommercielle sammenhænge. Selv software giganter som Microsoft har Open-source't deres ny .NET Core framework på Github, og er i næsten samme moment lykkedes med at overtage Github og fortsætte driften af samme uden store sværdslag.

Her på sitet kan man finde udmærkede definitioner af hvad Open Source er, og oplistning af de fordele Open Source kan tilbyde. Hvordan man opnår succes med sit open-source projekt er en anden sag, der handler mere om betingelserne rundt om selve projektet, end om licensen og kodens tilgængelighed.

Nu kan succes selvfølgelig være mange ting, men givet ideen bag Open Source projekter er at forene kræfter omkring at bygge noget software, som kan være til fælles nytte og glæde, så har jeg her forudsat at Open Source projekters succes er koblet til deres udbredelse, og den nytteværdi giver til dem der anvender den.

Typer af Open Source software

Moderne Open Source applikationer er sjældent skabt som monolitiske kodestrukturer, hvor alt koden, der ligger til grund for applikationen, er skabt af udviklere knyttet til selve applikationen. De fleste applikationer bygger på andre frameworks og komponenter, som bliver stykket sammen med egen kode for at opbygge en applikation.

Framework: En samling af funktioner bygget op i til et sammenhængende system, som tilbyder nok funktionalitet til at det kan fungere som grundlag for softwareudvikling i et givet miljø. Fx ASP.NET, Angular, Laravel og Ruby on Rails

Komponent: En fokuseret stykke software designet til at løse et enkelt problem og produceret til at blive brugt i som en del af en applikation bygget i et framework. Komponenter distribueres ofte ved hjælp af såkaldte package feeds fx npmjs.org, nuget.org eller phppackages.org.

Det er klart at deciderede Open Source Applikationer som fx Drupal og Umbraco, ikke kunne være Open Source, hvis ikke de frameworks og komponenter, der indgår i dem, også var udgivet under licenser, som tillader videredistribuering. Der er masser af frameworks og komponenter, som er bygget på den måde og det er interessant at se, hvordan et Open Source CMS som Umbraco er bygget oven på backend framework'et ASP.NET, frontend framework'et AngularJS, 14 backend komponenter og over 30 frontend komponenter (som sandsynligvis selv har en række afhængigheder på andre komponenter).

Det er altså værd at huske på, at langt fra al Open Source software er egentlige applikationer. Der er er en stor underskov af frameworks og komponenter, som tilføjer værdi på tværs af en lang række af projekter, og som ikke rigtigt bliver omtalt uden for deciderede udviklermiljøer. Som udvikler har jeg draget nytte af langt flere forskellige frameworks og komponenter end deciderede applikationer, og jeg tror, der et stort potentiale for at lave succesfulde Open Source projekter, der udgives som frameworks eller komponenter også i offentlige samarbejder som OS2.

Brugernes behov

Som mangeårig forbruger af Open Source har jeg udviklet nogle præferencer og nogle særlige træk, jeg kigger efter, når jeg skal vurdere, om jeg tør inddrage et stykke Open Source software i det projekt, jeg er ved at gå i gang med. Det varierer selvfølgelig lidt, hvordan jeg søger mine oplysninger, afhængigt af om det er en applikation, et framework eller en komponent jeg leder efter, men for alle typer gælder det, at det der er vigtig for mig som rådgiver, arkitekt og udvikler er:

1. Er produktet nemt tilgængeligt, findes det der hvor jeg normalt leder efter open source?
2. Findes der god dokumentation: "Sådan kommer du i gang", "Sådan kommer du videre", "Sådan bidrager du"?
3. Ser det ud til at være under aktiv udvikling, hvornår var seneste commit til source koden, hvornår var seneste release, hvornår var seneste kommentar eller status-skift på et rapporteret issue?
4. Er der mange issues med softwaren, hvilke typer af issues er det, er det ændringsforslag og forslag til ny funktionalitet, eller er det bug-rapporter?
5. Er der et community forum, er der en venlig stemning, virker det som om folk får hjælp med de issues, de har?

OS2s projekter

Jeg er en stor fan af Open Source, og jeg elsker ideen om at Open Source principperne kan bruges til at skaffe os alle sammen, gode og prisbillige løsninger på fælles problemer. Derfor ville jeg elske at se OS2-samarbejdets projekter i nogle af de løsninger, jeg som leverandør kan være en del af. Men hvad er egentlig status på samarbejdets projekter, hvis man kigger på dem i forhold til de kriterier, jeg oplister under overskriften "Brugernes behov" længere oppe?

Jeg har gået projekterne igennem i forhold til min behovs-checkliste og fandt følgende:

1. 17 ud af 23 projekternes source kode findes på Github og 4 ud af 23 på Bitbucket, dvs. langt størstedelen er tilgængelige og de fleste også via Github, som er de facto standarden for Open Source projekter i dag. 2 projekters kildekode kunne jeg slet ikke finde frem til - og det gør det vel lidt svært at betegne dem som "Open Source".
2. Af de 23 projekter kunne jeg finde nogenlunde dækkende information om anvendelse, set-up og bidrag for 7 af dem, delvis dækkende information for 8 af dem, og slet ingen information for 8 - i praksis ville det for mig betyde, at jeg for mindst 16 af de 23 projekter allerede her ville overveje at finde en anden løsning. Hvis ikke jeg kan finde information til at komme i gang med, så får jeg aldrig afprøvet produktet.
3. Det lykkedes mig kun at finde en åben isssue-liste for 2 af de 23 projekter, så for langt de fleste projekters vedkommende kan jeg ikke danne mig noget indtryk af, om issues bliver løst og om der arbejdes aktivt på projekterne. Mange af projekterne har links til Issue lister, som er gemt bag logins - men det er ikke altid tydeligt, hvorfor de er gemt bag logins, og hvad der skal til for at få adgang til dem.
4. Så vidt jeg kan se er der ikke et eneste af projekterne, som har tilknyttet en eller anden form for åbent forum hvor brugerne udveksle erfaringer og hjælpe hinanden.

For en del af produkterne gælder det, at der er hjælp at hente, i form af private virksomheder, der fungerer som projektejere, hvor jeg også har mulighed for at købe hjælp til opsætning og hosting - men jeg sidder tilbage med en fornemmelse af at en stor del af projekterne mere er Open Source af navn end af gavn.

Der ser ikke ud til at være et reelt open source samarbejde om særlig mange af produkterne. Langt de fleste har ikke åbne issue lister eller vejledninger i at bidrage, og kun ganske få af dem så ud til at have åbne pull-requests altså eksempler på at nogen har bidraget med kode til projekterne.

Stort set alle produkterne er på applikationsniveau og nogle enkelte er på komponentniveau. Måske er der et potentiale i at udvikle flere komponenter som kan finde anvendelse i udviklingsprojekter rundt omkring i det offentlige Danmark. Det kunne fx være opgave fokuserede komponenter til eksisterende Open Source projekter: En komponent som hjælper redaktører med at checke website tilgængelighed til ofte benyttede Open Source CMS'er som Drupal og Umbraco. Der kunne være synergieffekter i at lave komponenter til begge CMS'er i samme projekt.

Men først og fremmest sidder jeg med en fornemmelse af, at der er et potentiale i at fokusere lidt mere på:

Open Source ejerens opgaver

Jeg kan ikke huske at have set et succesfuldt open source projekt, som ikke har en person, eller en gruppe af personer, der føler en form for ejerskab for projektet. Det skyldes nok, at langt det meste software aldrig bliver færdigt og at der altid vil være behov for at opdatere og vedligeholde softwaren, og at der derfor er brug for at der er nogle personer involveret over tid, som kender til funktionerne og kodestrukturen.

Open Source konceptet åbner udviklings- og udgivelsesprocessen på en måde, der gør det muligt at crowdsource udviklingen, men brugerne af softwaren, uanset softwaretypen, har brug for et stykke software, der er konsistent og sammenhængende for at kunne bruge og videreudvikle på det, og disse egenskaber er som hovedregel ikke egenskaber som opstår af sig selv i software, det kræver en eller flere personer, der arbejder ud fra fælles forståelse.

Hvis vi anerkender at succesfuld software er software, som er udbredt og giver værdi til dets brugere, hvad er så de vigtigste opgaver der skal løses for at skabe et fundament softwaren kan vokse på? Det er efter min mening at projektet har Maintainers, en gruppe af personer, som påtager sig opgaven at fungere som softwarens vedligeholdere. Gruppen skal være synlig og det skal være tydeligt hvordan man kan komme til at kommunikere med gruppen. Denne gruppes vigtigste opgave er at facilitere udviklingen af softwaren, og de vigtigste opgaver her er:

1. Opret og vedligehold projektets udviklingsplatform, alle software projekter har brug for en platform til at dele source-code, håndtere pull-requests, gennemføre tests og builds og publicere og drive kommunikationen om projektet.
2. Hav styr på softwarens formål og vision, og sørg for at kommunikere det tydeligt så softwarens målgruppe kan finde oplysningerne og forstå dem. Det sikrer at brugerne forstår hvad softwaren kan og hvad den ikke kan, og hvad man gerne vil have software til at kunne i fremtiden.
3. Opret og udgiv et roadmap, det skal være tydeligt for eventuelle brugere hvor softwaren er mht. funktionalitet på nuværende tidspunkt, og hvilke funktionaliteter man gerne vil tilføje i fremtiden, gerne en plan med milestones. Hvis man ikke kan sætte datoer for milestones pga. usikkerhed omkring udviklerresourcer er roadmap'et et godt sted at highlighte hvad man har brug for hjælp til.
4. Opret og vedligehold en issue-liste og sørg for at den er åben og tilgængelig for tilføjelser fra brugerne. Sørg for at gennemse listen jævnligt, svar på oprettede issues, og kommentarer på eksisterende issues. Issues skal lukkes når de er løst eller afvist, og de skal bruges til at diskutere softwarens udvikling. Issue listen er det nemmeste sted at illustrere fremgang med projektet, og som sådan et essentielt element for deltagernes arbejdsglæde.
5. Formuler og publicer processer, regler og forventninger for bidrag til projektet, sammen med formål, vision, roadmap og issue-liste. Det hjælper bidragsydere til at forstå hvilke bidrag der er behov for og hvordan man kan bidrage. Det kan føles som om man sætter grænser for bidrag, men husk på at de fleste mennesker som ønsker at bruge sparsom fritid (eller betalt arbejdstid for den sags skyld), sætter pris på at have en fornemmelse af at deres indsats har størst mulig effekt.

Ovenstående liste kan i vidt omfang genfindes i denne artikel på Open Source Guides, hvor du også kan læse mere uddybende om emnerne, og finde links til andre interessante artikler på området.

Når man kigger ned over ovenstående liste bliver det hurtigt tydeligt, at de primært handler om planlægning og kommunikative opgaver, og man skal ikke være blind for at disse opgaver i vidt omfang ikke ses som attraktive opgaver for de personer der oftest bliver involveret først: Nemlig programmører.

Jeg tror, der er et stort potentiale i at bruge OS2-samarbejdets organisation og ressourcer til at arbejde mere på at lave en god moderne ramme omkring de eksisterende og fremtidige produkter. Jeg vil gerne opfordre til, at man udstikker nogle retningslinjer for source-kodens placering, readme filer, issue lister, wiki'er, og opretter en funktion, der kan hjælpe de forskellige projekter med at få disse ting på plads.