Slik etablerer du et åpen kildekode-program

Fullført

Her diskuterer vi de viktigste vurderingene for å etablere et åpen kildekode-program.

Hva mener vi med «åpen kildekode?»

Et åpen kildekode-program er mer enn offentlig tilgang til en kodebase. Det handler om å åpne opp et levende prosjekt for deltakelse fra alle som ønsker å bli involvert. Når det utføres riktig for et passende prosjekt, kan et åpen kildekode-program bidra til å forbedre produktets kvalitet betydelig.

En av de viktigste grunnene til at selskaper åpne kildeprosjekter er at de ønsker at samfunnet skal bli involvert. Populære prosjekter mottar betydelige bidrag fra fellesskapet, og de får det gratis.

Det er ikke nødvendigvis ute av altruisme. Personer og organisasjoner forbruke prosjekter fordi de ser en personlig eller forretningsmessig fordel. Når prosjektet ikke oppfyller deres behov eller forventninger, kan de bruke muligheten til å løse feil eller legge til funksjoner. I stedet for å holde disse forbedringene tilbake i private gafler, er de tvunget til å bidra disse endringene tilbake til kilderepositoriet for å bli en del av prosjektets opprinnelige plan. Denne dydige forbedringssyklusen er grunnen til at mange bedrifter produsere programvare ved hjelp av åpen kildekode-modellen.

Mål for åpen kildekode

For å oppsummere, er det tre dimensjoner til deltakelse i åpen kildekode-programvare:

• Forbrukere, som studerer eller bruker andres repositorier.
• bidragsytere, som aktivt er involvert i forbedring av andres repositorier.
• Producers, som bygger og vedlikeholder sine egne repositorier som er åpne for andre.

Etter hvert som organisasjoner tenker dypere på hva de ønsker å få ut av hver dimensjon, er det en god praksis å ta vare på hvor de er i dag. Det finnes fem prosessnivåer innenfor hver dimensjon.

• Ad hoc, som ikke har noen prosess på plass. Suksess avhenger av individuell innsats.
• Administrert, som har en delvis dokumentert prosess. Suksess avhenger av disiplin.
• Definert, som har en dokumentert, standardisert og integrert prosess. Vellykket avhenger av automatisering.
• Målt, som har en kvantitativt administrert prosess. Suksess avhenger av måling av måledata mot forretningsmål.
• Optimalisert, som har en prosess som kontinuerlig og pålitelig forbedres gjennom både trinnvise og innovative endringer. Suksess avhenger av å redusere risikoen for endring.

Hvis du vil ha en bedre forståelse av hvor organisasjonen står, kan du se selvvurderinger med åpen kildekode.

Hva bør du åpne kilde?

Mange prosjekter er ikke bestemt for åpen kildekode-storhet. Selv om kriteriene kan variere basert på firmaets mål og prosessnivå, er det noen anbefalte kriterier du bør vurdere før du åpner et prosjekt:

• Inneholder prosjektet åndsverk som du vil beskytte? I så fall vil åpning av kilden gi bort verdien. Ikke åpne kildekode slike prosjekter med mindre du føler at fordelene oppveier risikoen.

• Er prosjektet i stabil tilstand med god kodekvalitet? Prosjektet trenger ikke å være perfekt, men potensielle bidragsytere kan gå bort hvis prosjektet er i forferdelig form til å begynne med.

• Er prosjektet nyttig for personer utenfor firmaet? Hvis ikke, får du sannsynligvis ingen deltakelse.

• Kan personer utenfor firmaet bidra? De trenger tilgang til alle prosjektavhengigheter, byggprosesser og alt annet som trengs for å kjøre prosjektet. Hvis de ikke kan kjøre den, kan de ikke bidra.

• Har teamet båndbredden til å støtte et åpen kildekode-program? Hvis ikke, vent til du gjør det. Hvis du åpner et prosjekt med åpen kildekode og ikke støtter det, kan du miste muligheten til å bygge et tillitsfullt fellesskap.

Disse spørsmålene er bare noen av de vanligste hensynene. Organisasjonen kan ha andre forretnings- eller samsvarsproblemer å huske på.

Utforme et åpen kildekode-program

Å kjøre et åpen kildekode-program ligner på å kjøre et InnerSource-program, men for et offentlig publikum. Som et resultat er det noen flere hensyn.

Angi fellesskapsforventninger

Filer som README.md og CONTRIBUTING.md er enda viktigere fordi de blir utsatt for personer som ikke har organisasjonskonteksten. De må evalueres fra perspektivet til noen utenfor selskapet for å sikre klarhet.

I tillegg er dine etiske retningslinjer en viktig policy å uttrykke. Standarden er å legge til en CODE_OF_CONDUCT.md fil i repositoriets rot og bruke den til å forklare virkemåten som forventes fra deltakere i fellesskapet. Flere grupper i organisasjonen bør se gjennom dette dokumentet, inkludert det juridiske teamet. Heldigvis er det mange standard koder for oppførsel tilgjengelig for å starte. Mange prosjekter bruker disse kodene as-is uten endring. Finn ut mer i Veiledning for åpen kildekode for god oppførsel.

Forbereder ansatte til å vedlikeholde et repositorium

Ansatte har kanskje ikke erfaring med å arbeide med åpen kildekode-fellesskapet. For å hjelpe dem med å forberede seg, anbefaler vi at selskapet tilbyr et sett med guider som dekker de viktigste tingene alle bør vite før de kommer i gang. Disse veiledningene bør legges inn i et internt repositorium eller en portal som vedlikeholdes regelmessig og bare er tilgjengelig for ansatte i firmaet. Følgende veiledninger er noen av de viktigste:

• En «Bør vi åpne kilde for dette prosjektet?» som gir et rammeverk for å avgjøre om et kandidatprosjekt skal være åpen kildekode eller ikke. Denne veiledningen kan være strukturert som et flytskjema, et sett med spørsmål eller en liste over vurderinger.

• En sjekkliste for oppsett som inkluderer alle arbeidselementene en gruppe må fullføre før og etter oppstarten av et prosjekt med åpen kildekode. Denne listen bør omfatte anskaffelse av godkjenning for prosjektet med åpen kildekode, kodegjennomganger for å sikre at sensitive data fjernes før prosjektet sendes direkte, et varemerke eller prosjektsøk med åpen kildekode for å sikre at det ikke er en navnekonflikt, og så videre.

• En kontaktliste for nøkkelpersoner i organisasjonen som kanskje må kontaktes i tilfelle direkte støtte fra vedlikeholderne kreves. Denne listen bør inneholde personer fra programvaresikkerhet, områdesikkerhet, juridisk, PR og så videre.

• En kobling til et startrepositorium som kan klones som utgangspunkt. Den bør inneholde et eksempel på VIKTIG-fil, lisens, etiske retningslinjer, en bidragsveiledning og eventuelle andre støttefiler som alle åpne kilde-prosjekter fra firmaet må ha. Det bør ikke inneholde noe du ikke ønsker ved et uhell presset til et offentlig publikum.

• En vedlikeholders guide som forklarer ansvaret en vedlikeholder har for å holde repositoriet sunt. Disse ansvarsoppgavene omfatter å holde repositoriumdokumentasjonen oppdatert, sikre at problemer og pull-forespørsler får oppmerksomheten til de riktige personene i tide, og så videre.

• En kommunikasjonsveiledning som gir vedlikeholdere veiledning for repositorium for noen av emnene du foretrekker å ikke inkludere i offentlige filer som README.md, CONTRIBUTING.mdeller CODE_OF_CONDUCT.md. Disse emnene kan være sensitive forretningsemner, for eksempel ikke å diskutere konkurrenter. eller flere generelle emner, for eksempel hvordan du gjenkjenner de viktigste bidragsyterne på riktig måte.

• En interne vanlige spørsmål som gir godkjente svar på vanlige spørsmål. Denne listen er spesielt nyttig hvis det finnes juridiske finesser i emnene firmaet kan diskutere i løpet av vedlikehold av et åpen kildekode-program.

• En lisenspolicy som viser hvilke lisenser som er godkjent eller avvist av den juridiske avdelingen for bruk av åpen kildekode eller bidrag.