En av de største fordelene med å bruke fri programvare (friprog) er at man selv kan løse problemer man måtte støte på eller gjøre nødvendige endringer. Siden kildekoden er fritt tilgjengelig kan hvem som helst gjøre dette som de vil. Det er dette man i friprog-verdenen kaller “scratching your own itch”: hvis man har et ønske er man ikke avhengig av at leverandøren skal fikse det, man kan gjøre det selv.

For å slippe å vedlikeholde sine egne endringer når man senere skal oppdatere til ny versjon av produktet kan man prøve å få disse sendt tilbake til prosjektet. Dette er en oversikt over hvordan denne prosessen kan fungere:

Søking

Noe av det første man bør gjøre er å finne ut om andre har hatt samme (eller liknende) ønske. Den enkleste måten å gjøre dette på er å starte med et enkelt søk på Google eller andre søketjenester. Man bør også gå på websiden til prosjektet og gjøre søk i forum/mailinglister/issue-tracker eller andre verktøy fellesskapet bruker. Det går som regel raskt å finne ut om det er en kjent irritasjon, eller om du er på sporet av noe nytt og spennende…

Hent koden

Det er viktig å ta utgangspunkt i den siste utgaven av kildekoden til prosjektet. Dette er greit både for å sjekke om noen andre allerede har implementert ønsket ditt, men også for å gjøre det enklere for deg selv å få dine endringer godtatt av de som administrerer prosjektet. Finn ut hvor kildekoden til prosjektet ligger, dette er typisk et eller annet versjonskontrollsystem. Last deretter ned siste utviklingsversjon. Denne kildekoden er nesten alltid mer oppdatert enn siste utgivelse (release).

Bygg koden

Det er alltid lurt å sørge for at koden er i en stabil tilstand før du begynner å endre på den. De fleste friprogprosjekter har instruksjoner om hvordan dette gjøres, enten i en README fil eventuelt i dokumentasjon på web. Dersom prosjektet også har automatiserte tester bør du sette deg inn i hvordan du kjører disse. Dette vil forenkle arbeidet med å lage en endring (patch).

Bruk riktig formatering

Når man skal bidra til friprogprosjekter er det viktig å følge formateringen til prosjektet. Dette kan f.eks. være å bruke samme form for tabulator, og at import-uttrykk ikke blir automatisk organisert. Dette vil øke sannsynligheten for at din endring blir godtatt. I noen miljøer kan det være lurt å slå av automatisk formatering av koden.

Skriv en test

Nå er vi klare til å begynne å endre på kodebasen. Det første du bør gjøre er å skrive en test som illustrerer feilen du ønsker å fikse (eventuelt bruker den funksjonaliteten du ønsker å legge til). Dette er nyttig senere for de som administrerer prosjektet. De kan kjøre testen du har skrevet (uten dine kodeendringer) og få en bekreftelse på at ønsket funksjonalitet ikke fungerer uten kodeendringene dine. Overtalelse er viktig når du skal bidra til fri programvare, og en feilende test er et sterkt argument for at nettopp dine kodeendringer bør flettes inn i prosjektet. Dersom prosjektet allerede har automatiserte tester bruker du det. Du kan eventuelt beskrive en manuell test dersom prosjektet ikke bruker automatiserte tester. Her er det faktisk mulig at testen din ikke vil avdekke noen feil. Dette skjer typisk hvis koden du hentet ned er nyere enn siste release.

Skriv en fiks

Nå som du har en test som illustrerer mangelen i kodebasen kan du begynne å kode. Du koder ganske enkelt til testen din passerer. Når du mener du er ferdig kjører du alle testene for å forsikre deg om at du ikke har ødelagt noe.

Dokumentasjon

Udokumentert funksjonalitet finnes ikke – i hvert fall ikke for vanlige brukere. Dersom din fiks endrer eller legger til funksjonalitet i produktet må du også oppdatere dokumentasjonen. Dersom dokumentasjonen ligger under versjonskontroll bør patchen din også inneholde oppdatert dokumentasjon. Dersom dokumentasjon ligger utenfor (f.eks. i en Wiki), bør du legge med en egen fil som beskriver den nye funksjonaliteten. Når endringen din flettes inn i den offisielle koden blir det enkelt å oppdatere dokumentasjonen også.

Opprydning

Noe av det viktigste ved patching av prosjekter er å gjøre endringene i kodebasen så små som mulig. Pass på å sjekke at ikke undøvendige linjeskift, organisering av import-uttrykk, eller innrykk kommer med i patchen. Det skal være så enkelt som mulig for eieren av prosjektet å se hva slags endringer patchen inneholder.

Distribuert versjonskontroll (DSCM)

Dersom prosjektet bruker et distribuert versjonskontrollsystem (DSCM) som Git eller Mercurial, har hvem som helst mulighet til å sjekke inn sine egne endringer i en kopi (fork) av den offisielle koden. Dette skjer uten at de som administrerer prosjektet behøver å gi tilgang på forhånd. Etter at du har sjekket inn og publisert dine endringer til din kopi kan du be administratoren (via epost, IRC, bug tracker eller andre kanaler) om å flette inn dine endringer.

Når du jobber med kode som ligger i et DSCM behøver du ikke å lage en patch fil. Eksempel:

• Git: git add fil_1 fil_2 fil_3 && git commit -m “La til støtte for verdensherredømme” && git push
• Mercurial: hg add fil_1 fil_2 fil_3 && hg commit -m “La til støtte for verdensherredømme” && hg push

Sentralisert versjonskontroll (CSCM)

For sentralisert versjonskontroll (CVS, Subversion, etc) lager man en diff-fil (patch) som legges som vedlegg til en ticket. Det er viktig at denne er så liten og ryddig som mulig for å skape minst mulig hodebry å flette (merge) inn endringer man har gjort. En diff-fil lages ved å stå i rotkatalogen for prosjektet man jobber med, og kjøre en diff-komando for SCM-verktøyet man bruker. F.eks:

• Subversion: svn diff -x -w > patch-description-1.diff

Løpenummeret i filnavnet brukes hvis man ønsker å endre patchen etter å ha submittet den, men før den har blitt flettet inn i trunk.

Tillatelse

Endringer du gjør i arbeidstiden eies vanligvis av enten arbeidsgiveren din eller kunden. Dersom du ønsker å publisere en patch du har laget på jobb må du derfor få samtykke fra eieren før du publiserer denne.

I noen organisasjoner kan det være vanskelig å få gjennomslag for å “gi bort” noe som de har betalt for å få laget. Men å sende slike bidrag tilbake kan faktisk lønne seg for kunden, fordi man da slipper å måtte vedlikeholde selv de lokale endringene man har gjort og å håndtere disse ved alle oppgraderinger.

Endringsmelding

Lag en ny endringsmelding (ticket/issue) i prosjektets endringshåndteringssystem (tracker) som beskriver endringene du har gjort. Legg ved alt av referanser og/eller filer som trengs for at prosjektet kan flette inn endringene (ref. til DSCM for eller diff-fil). Skriv en kort, men konsis beskrivelse av hvorfor nettopp din endring bør tas inn i prosjektet.

Vedlikehold av endring

Det kan i enkelte tilfeller ta flere uker før noen ser på din patch. I mellomtiden er det viktig å vedlikeholde endringene dine. Synkroniser kode opp mot endringer som gjøres i trunk, og ved eventuelle konflikter, løs opp i disse, og send en ny patch (med nytt løpenummer) i samme endringsmelding.

Oppsummering

Første gang man bidrar til åpen kildekode kan det være forvirrende å vite hvor man skal begynne. Vi håper denne lille introduksjonen hjelper deg et lite stykke på vei. Hvis du står fast er det beste du kan gjøre å stille spørsmål i prosjektets diskusjonsforum. Hackere er stort sett takknemlige for all hjelp de kan få og hjelpsomme overfor nykommere. Lykke til!