10.18 Open source-programkontor (OSPO) og upstream-bidrag

Overblik og motivation

Jeres organisation kører allerede på open source-software: de operativsystemer, sprog, databaser og biblioteker, der bærer jeres produkt, er for det meste skrevet af folk, der ikke arbejder for jer. Kapitel 10.3 dækker indkøb og licenscompliance, og kapitel 10.12 dækker åben-versus-lukket-beslutningen. Dette kapitel handler om den funktion, der gør alt det sammenhængende: et open source-programkontor (OSPO), det team, der ejer, hvordan virksomheden forbruger, bidrager til og udgiver open source. Et OSPO er tyngdepunktet for en relation, der ellers er spredt over hver ingeniør, der skriver import.

De fleste organisationer bakker ind i open source én afhængighed ad gangen og opdager så den ophobede eksponering på én gang: et licensspørgsmål under due diligence ved et opkøb, et kritisk bibliotek med én udmattet vedligeholder, en sikkerhedsadvarsel i kode, ingen vidste de leverede. Et OSPO forvandler den panik til en styret kapabilitet. Det sætter forbrugspolitik, der muliggør frem for blokerer, det afgør, hvornår bidrag upstream tjener forretningen, det forvalter de projekter, I udgiver, og det anvender åbent samarbejde inde i virksomheden gennem InnerSource. Det er en strategisk funktion, forbundet med jeres softwareudviklingsværdier (kapitel 1.1), ikke et afkrydsningsfelt for compliance.

For virksomheder er driveren skala: tusinder af afhængigheder, eksport- og licensforpligtelser på tværs af jurisdiktioner og hundredvis af ingeniører, der hver træffer små open source-beslutninger dagligt. Et enkelt kontor giver den vildtvækst en rygrad. For det offentlige er driveren politik og offentlig tillid. “Open source som standard” og “public money, public code” er i stigende grad loven, så offentlige organer har brug for nogen, der kan offentliggøre kode sikkert, genbruge på tværs af agenturer og holde leverandører til åbne standarder. I begge sammenhænge betaler OSPO’et sig selv ved at konvertere usynlig, uprisat risiko til bevidst, budgetteret arbejde.

Grundprincipper

Open source er et tovejsforhold, ikke et gratis varelager. I forbruger, I bidrager, og I udgiver, og et OSPO ejer alle tre.
Bidrag er strategi, ikke velgørenhed. Upstreaming reducerer omkostningen ved at bære private patches og køber indflydelse.
Muliggør den hurtige sti, vogt ikke porten. En politik langsommere end at kopiere kode bliver ignoreret, så gør den kompatible sti til den hurtigste.
Finansiér de vedligeholdere, I afhænger af. Fællesgodet er ikke selvbærende, og jeres mest kritiske bibliotek kan have én ulønnet forfatter.
Forvalt det, I udgiver, eller udgiv det ikke. Et forladt projekt skader jeres omdømme mere, end noget projekt nogensinde ville.
Mål engagement, så I kan forbedre det. Tæl bidrag, afhængighedssundhed og tid-til-godkendelse, ikke pressemeddelelser.
I det offentlige: vælg åbent som standard, og offentliggør som standard. Åbenhed er normen; lukkethed er den dokumenterede undtagelse.

Anbefalinger

Rejs et OSPO dimensioneret til jeres virkelighed

I behøver ikke et stort team for at begynde. I et startup kan et OSPO være én ingeniør med et skriftligt mandat og nogle få timer om ugen. I en virksomhed er det en lille central gruppe plus et fødereret netværk af ambassadører indlejret i produktteams. Uanset størrelsen så giv det et klart charter, der dækker fire ansvar: forbrugspolitik og compliance, upstream-bidrag, udgivelse og forvaltning af jeres egne projekter og fællesskabs- og finansieringsrelationer. Placér det, hvor det kan se både ingeniørarbejde og jura, ofte rapporterende til CTO’en eller en ingeniørdirektør med en stiplet linje til jura og sikkerhed. Fejlformen er et OSPO, der bor helt inde i jura og bliver en bremse; rettelsen er at bemande det med ingeniører, der leverer, så dets vejledning bærer troværdighed hos de teams, det betjener.

Forbrug ansvarligt, og gør den sikre sti til den lette sti

Forbrug er, hvor det meste risiko kommer ind, så gør god adfærd uanstrengt. Tilbyd et kurateret internt katalog af forhåndsefterprøvede komponenter, automatiseret licens- og sårbarhedsscanning i pipelinen og klare standarder, en udvikler kan følge uden at indgive en ticket. Støt jer til licensdisciplinen i kapitel 10.3 og forsyningskæde- og afhængighedssundhedspraksisserne i kapitel 2.18: fastlås versioner, generér en software bill of materials, hold øje med softwareforsyningskæden for kompromitterede eller forladte pakker, og følg end-of-life, før det tvinger en migrering. OSPO’ets job er ikke at godkende hver afhængighed i hånden. Det er at bygge rækværket, så femoghalvfems procent af valgene er sikre automatisk, og kun de reelt usædvanlige tilfælde når et menneske.

Bidrag upstream, fordi det betaler sig, ikke fordi det er rart

Behandl upstream-bidrag som en økonomisk beslutning. Hver privat patch, I bærer mod en afhængighed, er en skat, I betaler ved hver opgradering, for evigt, til ændringen lander upstream, eller forken afviger så langt, at I ejer den helt. At bidrage rettelsen tilbage sletter den skat. Upstreaming køber også indflydelse over retning, så køreplanen for en komponent, I støtter jer til, bøjer sig mod jeres behov, og det signalerer kompetence til de ingeniører, I vil ansætte. Giv jeres udviklere en hurtig, dokumenteret sti: en forhåndsgodkendt bidragsyderlicensaftale eller developer certificate of origin, en let godkendelse, der bekræfter, at ændringen er sikker at dele, og ledelsestid budgetteret til arbejdet. Når alternativet er at vedligeholde en permanent fork af et projekt, I ikke kontrollerer, er det næsten altid billigere at bidrage tilbage.

Udgiv jeres egne projekter med reel styring

Når I open sourcer software, I byggede, så gør det bevidst eller slet ikke. Afgør først, om koden er en råvare værd at dele eller en differentiator værd at holde lukket, ved hjælp af ræsonnementet i kapitel 10.12. Hvis I udgiver, så vælg en licens, der matcher jeres hensigt (permissiv for at maksimere adoption, copyleft for at holde økosystemet gensidigt), dokumentér, hvem der afgør hvad, gennem en skriftlig styringsmodel, og registrér varemærket på projektnavnet, så I kan beskytte det mod misbrug, mens koden holdes fri. Forpligt jer til reel forvaltning: en offentlig issue-tracker, en bidragsguide, en adfærdskodeks og en sikkerhedspolitik med koordineret offentliggørelse, så anmeldere ved, hvordan de når jer (kapitel 4.2). Navngiv en vedligeholder, og budgettér deres tid. Et projekt, I lancerer med fanfare og forlader om et år, gør mere skade på jeres omdømme end et, I aldrig leverede.

Anvend InnerSource til at samarbejde inde i virksomheden

De vaner, der får open source til at virke (offentlige repositories, klare bidragsguides, gennemgang efter fortjeneste, lave barrierer for en første patch), virker lige så godt bag firewallen. InnerSource betyder, at enhver ingeniør kan finde, bruge og forbedre ethvert internt projekt og sende en pull request på tværs af teamgrænser i stedet for at indgive en ticket og vente. Det nedbryder siloer, spreder kodegenbrug og træner jeres folk i netop den arbejdsgang, de vil bruge, når de bidrager eksternt. OSPO’et er det naturlige hjem for InnerSource, fordi det allerede ejer værktøjet og den kulturelle håndbog. Begynd med nogle få værdifulde fælles biblioteker, offentliggør deres bidragsguides internt, og beløn teams, der tager imod eksterne patches elegant.

Finansiér og understøt de vedligeholdere, I afhænger af

Jeres produktionssystem kan hvile på et bibliotek vedligeholdt af én person i deres fritid. Det er en forsyningskæderisiko, og det ærlige svar er at hjælpe med at bære byrden. Identificér jeres mest kritiske afhængigheder fra jeres materialefortegnelse, find dem med en tynd vedligeholderbase, og vælg et svar for hver: sponsorér vedligeholderen direkte, bidrag med ingeniørtid, tilslut jer en fond, der finansierer projektet, eller, som en sidste udvej, forbered at forke eller erstatte. At finansiere fællesgodet er billigere end den nødsituation, der følger efter dets kollaps, og det holder de komponenter, I støtter jer til, sunde og i bevægelse i en retning, I kan påvirke.

Sæt bidragspolitik, der godkender hurtigt

En bidragspolitik findes for at sige ja hurtigt, ikke nej langsomt. Angiv, hvad en ingeniør må bidrage med uden at spørge (fejlrettelser, dokumentation, små funktioner til projekter, I allerede bruger), hvad der kræver et let tjek (alt der berører en differentiator eller et patent), og hvordan intellektuel ejendomsret og bidragsyderaftaler håndteres én gang, centralt, frem for pr. bidrag. Automatisér de kedelige dele: licenstjek, en forhåndsunderskrevet virksomhedsbidragsyderaftale og en bot, der flagger de sjældne indsendelser, som har brug for menneskelige øjne. Mål tid-til-godkendelse, og behandl en langsom kø som en fejl i politikken.

Afvejninger: fordele og ulemper

Tilgang	Fordele	Ulemper
Centralt OSPO	Ensartet politik, dyb ekspertise, klart ejerskab	Kan blive en flaskehals, hvis det kun lukker og aldrig muliggør
Fødereret OSPO (ambassadører i teams)	Skalerer, holder beslutninger tæt på ingeniører	Kræver stærk koordinering, ellers driver politikken fra hinanden
Bidrag upstream	Sletter private-patch-skatten, køber indflydelse, hjælper rekruttering	Løbende indsats, IP-gennemgang, arbejde på en andens tidsplan
Bær private forks	Fuld kontrol, lever på jeres tidslinje	Permanent vedligeholdelsesskat, driver fra upstream-sikkerhedsrettelser
Udgiv jeres eget projekt	Økosystem, omdømme, delt vedligeholdelse	Reel forvaltningsomkostning; forladelse skader omdømmet
Finansiér vedligeholdere	Beskytter kritiske afhængigheder, køber velvilje	Direkte omkostning, og at vælge hvem der skal finansieres er politisk
Intet OSPO (ad hoc)	Nul opsætningsomkostning	Usynlig juridisk, sikkerheds- og bæredygtighedsgæld

Den centrale spænding er mellem kontrol og muliggørelse. Et OSPO, der gennemgår hver afhængighed og hvert bidrag i hånden, føles sikkert, men bliver det, ingeniører går udenom, hvilket producerer de usynlige skyggeafhængigheder, I forsøgte at forebygge. Et OSPO, der kun udgiver blot muntre vejledninger uden nogen automatiseret håndhævelse, ignoreres i det øjeblik, en deadline truer. Løsningen er den samme, der løber gennem kapitel 10.3: automatisér det almindelige tilfælde, så den kompatible sti er den hurtigste sti, og forbehold menneskelig dømmekraft til det reelt nye. Få den balance rigtig, og kontoret er en kraftmultiplikator; få den forkert i begge retninger, og det er enten en bremse eller en dekoration.

Spørgsmål til drøftelse med dit team

Hvem ejer jeres relation til open source i dag, og kunne de besvare et hårdt spørgsmål i morgen? Hvis en potentiel opkøbers jurister bad om jeres licensfortegnelse, eller en journalist spurgte, hvilket uvedligeholdt bibliotek der sidder i jeres betalingssti, er der så et navn knyttet til svaret? For de fleste organisationer er det ærlige svar “ingen”, hvilket betyder, at hver ingeniør stille laver politik, og ingen er ansvarlig for summen. Tag dokumentation med til mødet: prøv at frembringe den godkendte licensliste, software bill of materials og den person, der ville besvare et copyleft-spørgsmål under due diligence. Hvis de artefakter ikke findes eller peger på ingen, har I fundet jeres første OSPO-opgave. Beslutningen at træffe er ikke, om I skal have funktionen, men hvem der ejer den og hvilket mandat de bærer, selv hvis kontoret er én person én dag om ugen.
Bærer I private patches, I kunne upstreame, og hvad koster det jer? Mange teams vedligeholder en stille bunke lokale ændringer mod deres afhængigheder, genanvender dem i hånden ved hver opgradering og absorberer flettesmerten, som var den en naturlov. Hver af de patches er en tilbagevendende skat, og hver er en kandidat til at bidrage tilbage, så skatten forsvinder. Tag detaljerne med: list de forks og lokale patches, jeres build faktisk bærer, estimér ingeniørtimerne hver koster pr. år, og notér hvilke upstream-projekter der sandsynligvis ville acceptere ændringen. Det modstridende hensyn er reelt, da upstreaming tager indsats nu og kører på vedligeholderens tidsplan, men sammenligningen er mod at betale patchskatten for evigt. Svaret bør forvandle “vi genanvender den bare altid” til et bevidst valg, med en bidragssti hurtig nok til, at ingeniører bruger den.
Hvilken afhængighed ville gøre mest ondt, hvis dens vedligeholder gik væk, og hvad vil I gøre ved det? Et sted i jeres stak er en komponent, der ville stoppe en omsætnings- eller missionskritisk tjeneste, hvis den gik i stykker, vedligeholdt af en person eller en håndfuld mennesker, I aldrig har finansieret eller takket. Fællesgodet føles gratis, lige til det øjeblik, det ikke er, og den dyre version af den lektie er en panik efter forladelse eller en upatchet sårbarhed. Tag jeres materialefortegnelse med, og rangér afhængigheder efter sprængradius, og notér så vedligeholderantal og finansieringsstatus for de øverste få. For hver kritisk, tyndt bemandet en så afgør på forhånd, om I vil sponsorere, bidrage med tid, tilslutte jer en fond eller forberede at erstatte. Det konverterer et latent enkeltstående fejlpunkt til en styret relation, holdt til samme standard som enhver anden driftsrisiko (kapitel 2.18).
Før I open sourcer det næste interne værktøj, er I klar til at forvalte det i årevis, eller leverer I en lancering og en eventuel undskyldning? En offentlig udgivelse er en stående forpligtelse: en issue-tracker nogen skal triagere, en sikkerhedsindbakke nogen skal holde øje med og et navn nogen skal forsvare. Teams rækker efter at open source for at hjælpe rekruttering eller velvilje og opdager så, at et forladt projekt med forældede issues skader det omdømme, de håbede at bygge, mere end at levere intet ville have. Tag dokumentation med: list de projekter, I allerede har udgivet, og vis for hver issue-alderen, om en navngiven vedligeholder har budgetterede timer, om det har en styringsmodel, et registreret varemærke og en koordineret offentliggørelsespolitik, og om koden er en råvare værd at dele eller en differentiator, I bør holde lukket (kapitel 10.12). Det modstridende hensyn er, at reel forvaltning koster ingeniørtid, I kunne bruge på produktet, så det ærlige valg er ofte at udgive færre ting og forvalte dem ordentligt. For en virksomhed betyder det juridisk og brandgennemgang før lancering; for det offentlige betyder det, at varemærket, offentliggørelseskanalen og undtagelsesprocessen for offentliggørelse som standard er afklaret, før repositoryet går offentligt.
Hvor lang tid tager det faktisk en ingeniør at få en afhængighed godkendt eller et bidrag frigivet, og er det langsommere end at gå udenom jer? En open source-politik konkurrerer direkte med den hurtigste omvej, en ingeniør kan finde, og enhver proces langsommere end at kopiere koden bliver omgået, hvilket producerer de usynlige skyggeafhængigheder, kontoret skulle forebygge. Spændingen er kontrol mod muliggørelse: hver manuel gennemgang tilføjer et revisionsspor og fanger det sjældne ægte problem, men den tilføjer også latens, der skubber det mediane tilfælde af den kompatible sti. Tag tallene med til mødet: den målte tid-til-godkendelse for en standardafhængighed og et standardbidrag, andelen af beslutninger håndteret automatisk versus af et menneske og antallet af undtagelser, der sidste kvartal reelt krævede dømmekraft. I en virksomhed med hundredvis af ingeniører, der hver træffer små beslutninger dagligt, bliver en to-dages kø stille til tusinder af omgåede gennemgange; i det offentlige støder den samme latens sammen med indkøbs- og revisionsforpligtelser, der kræver det papirspor, omvejen springer over, så rettelsen er at automatisere det almindelige tilfælde frem for at bemande en større port.
Hvilke interne projekter ville have mest gavn af InnerSource, og hvad forhindrer et andet team i at sende jer en pull request i dag? De praksisser, der får open source til at virke (offentlige repositories, bidragsguides, gennemgang efter fortjeneste, en lav barriere for en første patch), betaler sig bag firewallen ved at nedbryde siloer, sprede genbrug og træne folk i netop den arbejdsgang, de vil bruge til at bidrage eksternt. Det modstridende hensyn er, at at åbne et internt projekt kræver en bidragsguide, ledig gennemgangskapacitet og en beslutning om, hvilken kode der skal forblive begrænset af sikkerheds- eller regulatoriske grunde. Tag detaljerne med: navngiv de værdifulde fælles biblioteker, notér hvilke der allerede offentliggør en intern bidragsguide, og beskriv, hvordan en pull request på tværs af teams håndteres i dag, om den bydes velkommen eller går tabt i en kø. For en virksomhed måles gevinsten i duplikerede interne bygninger undgået på tværs af mange teams; for det offentlige strækker den samme vane sig på tværs af agenturgrænser som genbrug mellem agenturer, så offentliggørelse som standard og fælles komponenter reducerer duplikeret offentligt forbrug frem for at mangedoble det.

Sektorperspektiv

Startup. Giv kontoret til én navngiven ingeniør i nogle få timer om ugen med et charter på én side, ikke et udvalg. Vælg som standard permissive licenser med en scanner i pipelinen, upstream kun de håndfuld private patches, der faktisk gør ondt ved hver opgradering, og opsæt en lille månedlig sponsorering til det solovedligeholdte bibliotek, I reelt ikke kan leve uden. Fart betyder mere end dækning her: en kompatibel sti hurtigere end at kopiere kode slår en grundig politik, ingen følger.

Lille virksomhed. I kommer ikke til at bemande et dedikeret OSPO, så køb kapabiliteten indlejret i værktøjer, I allerede kører: en scanner, der flagger licens- og sårbarhedsproblemer, og et kurateret katalog af forhåndsefterprøvede komponenter. Ram arbejdet ind som licenscompliance- og afhængighedssundhedshygiejne frem for et program: vid hvad der er i jeres software bill of materials, vid hvad hver licens forpligter, og vid hvilken afhængighed med én vedligeholder der ville gøre ondt, hvis den forsvandt. Foretræk at købe scanning og kataloger frem for at bygge jeres egne.

Stor virksomhed. Kør et lille centralt kontor plus et fødereret netværk af ambassadører indlejret i produktteams, så politik forbliver ensartet, mens beslutninger forbliver tæt på ingeniører. Automatisér licens-, sårbarheds- og eksportscanning, dæk hver ingeniør med en forhåndsgodkendt bidragsyderaftale, og følg tid-til-godkendelse som en rapporteret måling. Finansiér de fonde, der står bag jeres kritiske afhængigheder, kør InnerSource på tværs af mange repositories, og styr hele ejendommen som en portefølje med sundheds- og engagementsmålinger frem for en spredning af individuelle beslutninger.

Offentlig sektor. Operér under open source som standard og public-money-public-code: offentliggør nye tjenester i et offentligt repository, medmindre en dokumenteret sikkerheds- eller privatlivsundtagelse gælder. Kør et katalog på tværs af staten, så teams genbruger, før de bygger, skriv open source- og åbne-standarder-krav ind i indkøb, så leverandører leverer genbrugelig kode med rettigheder beholdt, og håndtér koordineret offentliggørelse for det, I udgiver. Finansiér vedligeholdelse af fælles biblioteker, flere agenturer afhænger af, så intet enkelt team stille ejer infrastruktur, hele staten støtter sig til.

Eksempler

Startup. Et startup på tyve personer gør sin ledende platformsingeniør til deltids-OSPO-ejer med et charter på én side. Hun sætter en simpel forbrugspolitik (permissive licenser forhåndsgodkendt, copyleft gennemgået, scanner i pipelinen), og hun bemærker, at teamet bærer tre private patches mod et open source-kø-bibliotek, genanvendt smerteligt ved hver opgradering. Hun upstreamer alle tre; to accepteres inden for en måned og sletter opgraderingsskatten for altid. Hun open sourcer ét lille internt værktøj med en rigtig README, en licens og en sikkerhedskontakt, mest for at tiltrække ingeniører, og hun opsætter en månedlig sponsorering til den solovedligeholdte parser, produktet afhænger af. Intet af dette kræver headcount, blot en navngiven ejer og et klart mandat.

Stor virksomhed. En global bank driver et centralt OSPO på seks personer plus et fødereret netværk af open source-ambassadører indlejret i hver produktgruppe. Det centrale team ejer politik, den automatiserede licens- og eksportcomplianceskanning og den bidragsyderlicensaftale, hver ingeniør er dækket af fra dag ét. Ambassadørerne håndterer lokal gennemgang og coacher deres teams i bidrag. Banken finansierer flere fonde, hvis projekter understøtter dens handelssystemer, bidrager rettelser upstream til et udbredt datarammeværk, så den holder op med at vedligeholde en fork, og kører InnerSource på tværs af to hundrede interne repositories, så ethvert team kan sende en pull request til ethvert andet. Tid-til-godkendelse for et standardbidrag er under to dage, følges som en måling, OSPO’et rapporterer kvartalsvis.

Offentlig sektor. Et nationalt digitalt agentur opererer under et mandat om “open source som standard” og public-money-public-code. Dets OSPO offentliggør nye tjenester i et offentligt repository, medmindre en dokumenteret undtagelse gælder for sikkerhed eller privatliv, kører et katalog på tværs af staten, så agenturer genbruger kode, før de bygger den, og skriver open source- og åbne-standarder-krav ind i indkøb, så leverandører leverer genbrugelig, veldokumenteret kode, hvor staten beholder rettigheder. Kontoret håndterer også koordineret sikkerhedsoffentliggørelse for den kode, det udgiver, og finansierer vedligeholdelse af et fælles identitetsbibliotek, flere agenturer nu afhænger af, så intet enkelt team stille ejer en komponent, hele staten støtter sig til.

Business case: motivation, ROI og TCO

Det klareste afkast er eliminering af undgåelige, dyre overraskelser. Uforvaltet open source producerer kriser, der ankommer på deres egen tidsplan: en copyleft-overtrædelse afsløret under due diligence ved et opkøb, en nødmigrering væk fra en død komponent, et brud sporet til en afhængighed, ingen fortegnelse listede. Et OSPO konverterer de lavsandsynlige, højomkostnings-begivenheder til jævnt, budgetteret arbejde. Læg de tilbagevendende besparelser ved upstreaming oven på: hver privat patch, I pensionerer, holder op med at beskatte hver fremtidig opgradering, og på tværs af en stor ejendom akkumulerer det til reel ingeniørkapacitet returneret til produktarbejde.

På samlet ejeromkostning-regnskabet er kontoret billigt i forhold til det, det beskytter. Dets omkostning er et lille team, noget scannings- og katalogværktøj og beskeden vedligeholderfinansiering. Sæt det mod omkostningen ved ikke at have det: juridisk ansvar, dumpet eller forsinket due diligence, sikkerhedshændelser, duplikerede interne bygninger af ting, der allerede findes som open source, og den langsomme blødning af forks, ingen valgte at beholde. Der er også opsideafkast, der er sværere at prissætte, men reelle: indflydelse over retningen for komponenter, I afhænger af, en rekrutterings- og omdømmefordel ved en troværdig open source-tilstedeværelse og hurtigere levering, fordi ingeniører genbruger i stedet for at genopbygge. Når I fremlægger sagen for ledelsen, så ram OSPO’et ind som forsyningskædestyring for størstedelen af jeres kodebase, med et strategisk udbytte oven på. I det offentlige så tilføj complianceaspektet, da åbenhed ofte er påbudt, og at gøre det godt undgår både manglende overholdelse og duplikeret offentligt forbrug.

Anti-mønstre og faldgruber

OSPO’et som en port. Et kontor, der kun gennemgår og blokerer, aldrig muliggør, bliver omgået og producerer de skyggeafhængigheder, det skulle forebygge.
Bidragsteater. At annoncere en open source-strategi, mens godkendelsesprocessen gøres så langsom, at ingen faktisk bidrager.
Den forladte udgivelse. At udgive et projekt med et lanceringsblogindlæg og så aldrig triagere et issue, hvilket skader omdømmet mere end tavshed ville.
Fork-og-glem. At forke en afhængighed for én rettelse og så bære den for evigt, og drive væk fra upstream-sikkerhedspatches.
At snylte på skrøbelige vedligeholdere. At afhænge af et kritisk bibliotek med én vedligeholder og aldrig finansiere, takke eller hjælpe personen bagved.
Varemærkeforsømmelse. At udgive et projekt uden at beskytte dets navn og så se en fork eller leverandør handle på jeres omdømme.
Kun juridisk ejerskab. At huse OSPO’et helt i jura, så dets vejledning ikke bærer nogen ingeniørtroværdighed, og teams ignorerer det.
Forfængelighedsmålinger. At tælle stjerner og pressenævnelser i stedet for afhængighedssundhed, tid-til-godkendelse og pensionerede private patches.

Modenhedsmodel

Niveau 1, Opstart: Ingeniører tilføjer, patcher og udgiver lejlighedsvis open source uden politik og uden ejer. Forbrug, bidrag og udgivelse er reaktive og ad hoc, drevet af individuelt initiativ. Private forks ophobes ubemærket, ingen finansierer noget upstream-projekt, og ingen kunne besvare et licensspørgsmål under due diligence.
Niveau 2, Udvikling: Grundlæggende praksisser dukker op, men varierer team for team. En grov forbrugspolitik og godkendt licensliste findes, og nogen er løst ansvarlig, men bidrag er langsomme og sag for sag, og nogle grupper gør langt mere end andre. Nogle få kritiske afhængigheder er kendt, men bæredygtighed, udgivelser og forvaltning forbliver inkonsistente.
Niveau 3, Standardisering: Et chartret OSPO ejer forbrug, bidrag, udgivelse og fællesskab, og praksisserne er dokumenteret og håndhævet på tværs af organisationen. Scanning og en software bill of materials er automatiseret, en forhåndsgodkendt bidragsyderaftale og en hurtig godkendelsessti findes, udgivne projekter bærer reel styring, varemærker og sikkerhedspolitikker, og InnerSource spreder sig. Offentlige teams offentliggør som standard.
Niveau 4, Styring: Open source-funktionen måles og styres mod baselines. Tid-til-godkendelse følges mod et mål, bidragsvolumen og upstream-accepteringsrate rapporteres, afhængighedssundheds- og vedligeholderantalsdashboards flagger enkeltstående fejlpunkter, finansieret-vedligeholder-dækning af de højest risikobelagte afhængigheder overvåges, og fortegnelsen over private patches og forks trender nedad kvartal for kvartal. Udgivne projekter har målte issue-responstider, undtagelser gennemgås efter en kadence, og forfængelighedsmålinger som stjerner droppes til fordel for disse.
Niveau 5, Orkestrering: Open source er en styret strategisk kapabilitet, integreret med ingeniør-, jura-, sikkerheds- og indkøbsplanlægning og løbende tilpasset. Bidrag er rutine, kritiske vedligeholdere og fonde finansieres, organisationen forvalter veldrevne projekter og styrer de økosystemer, den afhænger af, og InnerSource er normen. Engagements- og sundhedsmålinger fodrer løbende forbedring, og porteføljen rebalanceres, efterhånden som afhængigheder, risici og mandater skifter.

Idéer til drøftelse

Hvor går linjen mellem et OSPO, der muliggør, og et, der lukker, og hvordan ville I vide udefra, hvilket I har bygget?
Hvilke af jeres private patches eller forks bærer I af vane frem for nødvendighed, og hvad skulle der til for at upstreame de øverste tre?
Hvordan bør I afgøre, hvilke vedligeholdere og fonde der skal finansieres, når listen over kritiske afhængigheder er længere end budgettet?
Hvad ville reelt ændre sig i jeres næste release, hvis I skulle udgive den med reel styring, et varemærke og en koordineret offentliggørelsespolitik fra dag ét?
For offentlige læsere, hvad er en forsvarlig proces til at undtage kode fra offentliggørelse som standard uden stille at udhule princippet?
Hvilke interne biblioteker ville have mest gavn af InnerSource, og hvad forhindrer et andet team i at sende jer en pull request i dag?

Vigtigste pointer

Et OSPO ejer hele relationen til open source: at forbruge ansvarligt, at bidrage upstream, at udgive jeres egne projekter og at opretholde de vedligeholdere, I afhænger af.
At bidrage upstream er strategi, ikke velgørenhed; det sletter den tilbagevendende skat af private patches, køber indflydelse over retning og hjælper jer med at rekruttere.
Gør den kompatible sti til den hurtigste sti gennem automatisering og kuratering, så kontoret muliggør ingeniører frem for at lukke dem.
Udgiv jeres egne projekter kun med reel styring, en valgt licens, et beskyttet varemærke og koordineret sikkerhedsoffentliggørelse, eller lad være med at udgive dem.
Finansiér og hjælp de kritiske vedligeholdere, jeres produktionssystem hviler på, fordi fællesgodet ikke er selvbærende.
Anvend InnerSource til at bringe open source-samarbejde ind i virksomheden, og i det offentlige så vælg åbent som standard, offentliggør som standard og genbrug, før I bygger.

Referencer og videre læsning

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labour Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper and Klaas-Jan Stol (editors), Adopting InnerSource: Principles and Case Studies
The Linux Foundation and TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation and TODO Group, State of OSPOs and Open Source Management (annual survey series)
Heather Meeker, Open (Source) for Business
Open Source Initiative, The Open Source Definition and approved-licence list
Free Software Foundation Europe, Public Money, Public Code campaign materials
U.S. Federal Source Code Policy and Code.gov guidance