Sådan opretter du et program med åben kildekode
Her diskuterer vi de vigtigste overvejelser i forbindelse med etablering af et program med åben kildekode.
Hvad mener vi med "åben kildekode?"
Et open source-program er mere end offentlig adgang til en kodebase. Det handler om at åbne et levende projekt for deltagelse fra alle, der ønsker at involvere sig. Når et open source-program udføres korrekt for et passende projekt, kan det hjælpe med at forbedre produktets kvalitet væsentligt.
En af de vigtigste årsager til, at virksomheder projekter med åben kildekode er, at de ønsker, at community'et skal involveres. Populære projekter modtager betydelige bidrag fra community'et, og de får det gratis.
Det er ikke nødvendigvis ud af altruisme. Personer og organisationer forbruge projekter, fordi de får vist en personlig eller forretningsmæssig fordel. Når projektet ikke opfylder deres behov eller forventninger, kan de bruge muligheden for at løse fejl eller tilføje funktioner. I stedet for at holde disse forbedringer tilbage i private gafler, er de nødt til at bidrage disse ændringer tilbage til kildelageret for at blive en del af projektets oprindelige plan. Denne gode forbedringscyklus er grunden til, at mange virksomheder producere software ved hjælp af open source-modellen.
Mål med åben kildekode
For at opsummere er der tre dimensioner at deltage i open source-software:
- Forbrugere, som studerer eller bruger andres lagre.
- bidragydere, som aktivt er involveret i forbedringen af andres lagre.
- Producenter, som bygger og vedligeholder deres egne lagre, der er åbne for andre.
I takt med at organisationer tænker mere dybt over, hvad de ønsker at få ud af hver dimension, er det en god idé at gøre status over, hvor de er i dag. Der er fem procesniveauer i hver dimension.
- ad hoc-, som ikke har nogen proces på plads. Succes afhænger af individuelle bestræbelser.
- Administreret, som har en delvist dokumenteret proces. Succes afhænger af disciplin.
- Defineret, som har en dokumenteret, standardiseret og integreret proces. Succes afhænger af automatisering.
- Målt, som har en kvantitativt administreret proces. Succes afhænger af måling af målepunkter i forhold til forretningsmål.
- Optimeret, som har en proces, der løbende og pålideligt forbedres gennem både trinvise og innovative ændringer. Succes afhænger af at reducere risikoen for ændringer.
Hvis du vil have en bedre forståelse af, hvor din organisation står, kan du se Selvvurderinger med åben kildekode.
Hvad skal du open source?
Mange projekter er ikke bestemt til storhed med åben kildekode. Selvom dine kriterier kan variere afhængigt af virksomhedens mål og procesniveau, er her nogle anbefalede kriterier, du skal overveje, før du åbner et projekt:
Indeholder dit projekt immaterielle rettigheder, som du vil beskytte? Hvis det er tilfældet, vil åbning af kilden give dens værdi væk. Undlad at åbne denne type projekter med åben kildekode, medmindre du føler, at fordelene opvejer risiciene.
Er projektet i en stabil tilstand med god kodekvalitet? Projektet behøver ikke at være perfekt, men potentielle bidragydere kan gå væk, hvis projektet er i forfærdelig form til at begynde med.
Er dit projekt nyttigt for personer uden for virksomheden? Hvis ikke, får du sandsynligvis ikke nogen deltagelse.
Kan personer uden for virksomheden bidrage? De skal have adgang til alle projektafhængigheder, bygge processer og hvad der ellers er nødvendigt for at køre projektet. Hvis de ikke kan køre den, kan de ikke bidrage.
Har dit team båndbredden til at understøtte et program med åben kildekode? Hvis ikke, skal du vente, til du gør det. Hvis du åbner et projekt med åben kildekode og ikke understøtter det, kan du miste muligheden for at oprette et tillidsbaseret community.
Disse spørgsmål er blot nogle af de mest almindelige overvejelser. Din organisation kan have andre forretnings- eller overholdelsesproblemer, du skal være opmærksom på.
Design af et program med åben kildekode
Kørsel af et open source-program svarer til at køre et InnerSource-program, men for en offentlig målgruppe. Derfor er der nogle flere overvejelser.
Indstilling af forventninger til community'et
Filer som README.md og CONTRIBUTING.md er endnu vigtigere, fordi de vises for personer, der ikke har din organisationskontekst. De skal evalueres ud fra en person uden for virksomheden for at sikre klarhed.
Derudover er din adfærdskodeks en vigtig politik at udtrykke. Standarden er at føje en CODE_OF_CONDUCT.md fil til lagerets rod og bruge den til at forklare den funktionsmåde, der forventes af deltagerne i dit community. Flere grupper i din organisation skal gennemse dette dokument, herunder dit juridiske team. Heldigvis er der mange standard adfærdskodekser til rådighed, hvorfra man kan starte. Mange projekter bruger disse koder as-is uden ændringer. Få mere at vide i Vejledning til adfærdskodekser med åben kildekode.
Forberedelse af medarbejdere til at vedligeholde et lager
Medarbejderne har muligvis ikke erfaring med at arbejde med community'et med åben kildekode. For at hjælpe dem med at forberede sig anbefaler vi, at virksomheden tilbyder et sæt vejledninger, der dækker de vigtigste ting, som alle skal vide, før de kommer i gang. Disse vejledninger skal sendes til et internt lager eller en portal, der vedligeholdes regelmæssigt og kun er tilgængelig for virksomhedens medarbejdere. Følgende vejledninger er nogle af de vigtigste:
En "Skal vi åbne kildekode til dette projekt?"-vejledning, der giver mulighed for at afgøre, om et kandidatprojekt skal have åben kildekode eller ej. Denne vejledning kan struktureres som et rutediagram, et sæt spørgsmål eller en liste over overvejelser.
En tjekliste til konfiguration, der indeholder alle de arbejdselementer, som et team skal fuldføre før og efter lanceringen af et projekt med åben kildekode. Denne liste bør omfatte erhvervelse af godkendelse til projektet med åben kildekode, kodegennemgange for at sikre, at følsomme data fjernes, før projektet går live, et varemærke eller projektsøgning med åben kildekode for at sikre, at der ikke er en navngivningskonflikt osv.
En liste over kontakter for nøglepersoner i din organisation, der muligvis skal kontaktes, hvis der kræves direkte support fra vedligeholdelsesmedarbejderne. Denne liste bør omfatte personer fra softwaresikkerhed, webstedssikkerhed, juridiske oplysninger, public relations osv.
Et link til et startlager, der kan klones som udgangspunkt. Den skal indeholde et eksempel på VIGTIGT, licens, ordensregler, bidragende vejledning og andre supplerende filer, som alle open source-projekter fra din virksomhed skal have. Den må ikke indeholde noget, du ikke vil have skubbet til en offentlig målgruppe ved et uheld.
En vedligeholdervejledning, der forklarer det ansvar, en vedligeholder har for at holde lageret sundt. Disse ansvarsområder omfatter at holde lagerdokumentation opdateret, sikre, at problemer og pullanmodninger får de rette personers opmærksomhed i tide osv.
En kommunikationsvejledning, der indeholder en vejledning til lagerholdere for nogle af de emner, du foretrækker ikke at medtage i offentlige filer, f.eks.
README.md,CONTRIBUTING.mdellerCODE_OF_CONDUCT.md. Disse emner kan være følsomme forretningsemner, f.eks. ikke at diskutere konkurrenter. eller mere generel udførelse af emner, f.eks. hvordan du korrekt genkender de største bidragydere.En interne ofte stillede spørgsmål, der giver godkendte svar på almindelige spørgsmål. Denne liste er især nyttig, hvis der er juridiske finesser i de emner, som din virksomhed kan diskutere i løbet af vedligeholdelsen af et program med åben kildekode.
En licenspolitik, der viser, hvilke licenser der er blevet godkendt eller afvist af den juridiske afdeling til brug eller bidrag med åben kildekode.