Succes med Open Source

I denne blog sætter Jesper Hauge, Head of Development hos Novicell, OS2s løsninger under lup og giver sit take på, hvordan der bedst skabes Open Source-successer.

Open Source – levedygtigt og værdifuldt?

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

OS2’s site kan man finde udmærkede definitioner af Open Source, og oplistning af fordele ved Open Source. 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.

Succes kan selvfølgelig være mange ting. Men givet idéen bag Open Source-projekter er at forene kræfter om 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 nytteværdi til dem, der anvender den.

Typer af Open Source-software

Moderne Open Source-applikationer er sjældent skabt som monolitiske kodestrukturer, hvor alt kode, 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ø. Det kan fx være ASP.NET, Angular, Laravel eller Ruby on Rails.

Komponent: En fokuseret stykke software designet til at løse et enkelt problem og produceret til at blive brugt 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 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. Jeg tror, at 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, som jeg fokuserer på i vurderingen af, om jeg tør inddrage et stykke Open Source-software i et givent projekt. Det varierer selvfølgelig lidt, hvordan jeg søger mine oplysninger afhængigt af, om det er en applikation, et framework eller en komponent, som jeg leder efter. For alle typer er de vigtige spørgsmål for mig som rådgiver, arkitekt og udvikler:

  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" og "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, at folk får hjælp med de issues, de har?

OS2’s projekter

Jeg er en stor fan af Open Source og elsker idéen 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, som 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 gennemgået projekterne i forhold til min behovs-checkliste og fandt følgende:

  • 17 ud af 23 projekternes source kode findes på Github og fire 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. To projekters kildekode kunne jeg ikke finde, og det gør det derfor svært at betegne dem som "Open Source".
  • Af de 23 projekter kunne jeg finde nogenlunde dækkende information om anvendelse, set-up og bidrag for syv af dem. Delvis dækkende information for otte af dem, og slet ingen information for otte. I praksis ville det 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, så får jeg aldrig afprøvet produktet.
  • Det lykkedes mig kun at finde en åben issue-liste for to 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.
  • Umiddelbart 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. Det kan være 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 og kun ganske få af dem har å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 opgavefokuserede komponenter til eksisterende Open Source-projekter: En komponent, som hjælper redaktører med at tjekke websitetilgæ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 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. Derfor er der brug for, at der over tid er nogle personer involveret, 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. 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, hvor det er vigtigt at have fokus på:

  • 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.
  • Hav styr på softwarens formål og vision. 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, hvad den ikke kan, og hvad man gerne vil have software til at kunne i fremtiden.
  • 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.
  • Opret og vedligehold en issue-liste. 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, som sådan et essentielt element for deltagernes arbejdsglæde.
  • Formuler og publicer processer, regler og forventninger for bidrag til projektet. Det kan gøres 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. 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 på at lave en velfungerende og 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.