10.18 Open source program office (OSPO) en bijdragen aan upstream

Overzicht en motivatie

Je organisatie draait al op open-sourcesoftware: de besturingssystemen, talen, databases en bibliotheken die je product dragen zijn grotendeels geschreven door mensen die niet voor jou werken. Hoofdstuk 10.3 behandelt inkoop en licentienaleving, en hoofdstuk 10.12 de beslissing tussen open en gesloten. Dit hoofdstuk gaat over de functie die dat alles coherent maakt: een open-source program office (OSPO), het team dat bezit hoe het bedrijf open source gebruikt, eraan bijdraagt en het uitbrengt. Een OSPO is het zwaartepunt voor een relatie die anders over elke engineer is verspreid die import typt.

De meeste organisaties glijden één afhankelijkheid tegelijk in open source en ontdekken dan de opgehoopte blootstelling in één klap: een licentievraag tijdens due diligence bij een overname, een kritieke bibliotheek met één uitgeputte beheerder, een beveiligingsadvies in code waarvan niemand wist dat ze die uitleverden. Een OSPO zet die wedloop om in een beheerd vermogen. Het stelt gebruiksbeleid dat mogelijk maakt in plaats van blokkeert, beslist wanneer bijdragen aan upstream het bedrijf dient, beheert de projecten die je uitbrengt en past open samenwerking binnen het bedrijf toe via InnerSource. Dit is een strategische functie, verbonden met de waarden van je software-engineering (hoofdstuk 1.1), geen compliancevinkje.

Voor ondernemingen is de drijfveer schaal: duizenden afhankelijkheden, export- en licentieverplichtingen over jurisdicties en honderden engineers die elk dagelijks kleine open-sourcebeslissingen nemen. Eén kantoor geeft die wildgroei een ruggengraat. Voor de overheid zijn de drijfveren beleid en publiek vertrouwen. “Open source als standaard” en “public money, public code” worden steeds vaker wet, dus publieke organen hebben iemand nodig die code veilig kan publiceren, over instanties kan hergebruiken en leveranciers aan open standaarden kan houden. In beide omgevingen betaalt de OSPO zichzelf terug door onzichtbaar, onbeprijsd risico om te zetten in bewust, begroot werk.

Kernprincipes

Open source is een tweerichtingsrelatie, geen gratis magazijn. Je gebruikt, je draagt bij en je brengt uit, en een OSPO bezit alle drie.
Bijdragen is strategie, geen liefdadigheid. Naar upstream bijdragen vermindert de kosten van eigen patches meedragen en koopt invloed.
Maak het snelle pad mogelijk, bewaak niet de poort. Een beleid trager dan code kopiëren wordt genegeerd, dus maak het conforme pad het snelste.
Financier de beheerders van wie je afhangt. De commons is niet zelfvoorzienend, en je meest kritieke bibliotheek kan één onbetaalde auteur hebben.
Beheer wat je uitbrengt, of breng het niet uit. Een verlaten project schaadt je reputatie meer dan geen project ooit zou doen.
Meet betrokkenheid zodat je haar kunt verbeteren. Tel bijdragen, afhankelijkheidsgezondheid en tijd-tot-goedkeuring, geen persberichten.
Kies bij de overheid standaard voor open en publiceer standaard. Openheid is de norm. Sluiting is de gedocumenteerde uitzondering.

Aanbevelingen

Zet een OSPO op naar de maat van je werkelijkheid

Je hebt geen groot team nodig om te beginnen. Bij een startup kan een OSPO één engineer zijn met een geschreven mandaat en een paar uur per week. Bij een onderneming is het een kleine centrale groep plus een gefedereerd netwerk van kampioenen ingebed in productteams. Geef haar, wat de omvang ook is, een helder handvest dat vier verantwoordelijkheden dekt: gebruiksbeleid en compliance, bijdragen aan upstream, je eigen projecten uitbrengen en beheren, en gemeenschaps- en financieringsrelaties. Plaats haar waar ze zowel engineering als juridische zaken kan zien, vaak rapporterend aan de CTO of een VP engineering met een stippellijn naar juridische zaken en beveiliging. De faalwijze is een OSPO die volledig binnen juridische zaken leeft en een rem wordt. De oplossing is haar te bemannen met engineers die uitleveren, zodat haar richtlijnen geloofwaardigheid dragen bij de teams die ze dient.

Gebruik verantwoord, en maak het veilige pad het makkelijke pad

Gebruik is waar het meeste risico binnenkomt, dus maak goed gedrag moeiteloos. Bied een gecureerde interne catalogus van vooraf gecontroleerde componenten, geautomatiseerd scannen op licenties en kwetsbaarheden in de pijplijn en heldere standaarden die een ontwikkelaar kan volgen zonder een ticket aan te maken. Leun op de licentiediscipline in hoofdstuk 10.3 en de praktijken voor toeleveringsketen en afhankelijkheidsgezondheid in hoofdstuk 2.18: pin versies, genereer een software bill of materials, bewaak de softwaretoeleveringsketen op gecompromitteerde of verlaten pakketten en volg einde van levensduur voordat het een migratie afdwingt. De taak van de OSPO is niet elke afhankelijkheid met de hand goedkeuren. Het is de vangrails bouwen zodat vijfennegentig procent van de keuzes automatisch veilig is en alleen de werkelijk ongewone gevallen een mens bereiken.

Draag bij aan upstream omdat het loont, niet omdat het aardig is

Behandel bijdragen aan upstream als economische beslissing. Elke eigen patch die je tegen een afhankelijkheid draagt is een belasting die je bij elke upgrade betaalt, voor altijd, tot de wijziging upstream landt of de fork zo ver uit elkaar loopt dat je hem helemaal bezit. De reparatie terugbrengen verwijdert die belasting. Upstreamen koopt ook invloed op de richting, zodat de roadmap van een component waarop je leunt naar jouw behoeften buigt, en het signaleert bekwaamheid aan de engineers die je wilt werven. Geef je ontwikkelaars een snel, gedocumenteerd pad: een vooraf goedgekeurde bijdrageovereenkomst of developer certificate of origin, een lichte goedkeuring die bevestigt dat de wijziging veilig te delen is en managementtijd begroot voor het werk. Wanneer het alternatief is een permanente fork onderhouden van een project dat je niet beheerst, is teruggeven bijna altijd goedkoper.

Breng je eigen projecten uit met echte governance

Wanneer je software die je bouwde als open source uitbrengt, doe het bewust of niet. Besluit eerst of de code een commodity is die het delen waard is of een onderscheidende zaak die gesloten moet blijven, met de redenering uit hoofdstuk 10.12. Als je uitbrengt, kies een licentie die bij je intentie past (permissief om adoptie te maximaliseren, copyleft om het ecosysteem wederkerig te houden), documenteer wie wat beslist via een geschreven governancemodel en registreer het handelsmerk op de projectnaam zodat je haar tegen misbruik kunt beschermen terwijl de code vrij blijft. Committeer je aan echt rentmeesterschap: een publieke issuetracker, een bijdragegids, een gedragscode en een beveiligingsbeleid met gecoördineerde openbaarmaking zodat melders weten hoe ze je bereiken (hoofdstuk 4.2). Noem een beheerder en begroot zijn of haar tijd. Een project dat je met veel tamtam lanceert en binnen een jaar verlaat doet meer schade aan je reputatie dan een dat je nooit uitleverde.

Pas InnerSource toe om binnen het bedrijf samen te werken

De gewoonten die open source laten werken (publieke repositories, heldere bijdragegidsen, review op verdienste, lage drempels voor een eerste patch) werken net zo goed achter de firewall. InnerSource betekent dat elke engineer elk intern project kan vinden, gebruiken en verbeteren, en een pull request over teamgrenzen stuurt in plaats van een ticket aan te maken en te wachten. Dit breekt silo’s af, verspreidt hergebruik van code en traint je mensen in precies de workflow die ze zullen gebruiken wanneer ze extern bijdragen. De OSPO is het natuurlijke thuis voor InnerSource omdat ze al de tooling en het culturele draaiboek bezit. Begin met een paar waardevolle gedeelde bibliotheken, publiceer hun bijdragegidsen intern en beloon teams die patches van buiten soepel accepteren.

Financier en ondersteun de beheerders van wie je afhangt

Je productiesysteem kan rusten op een bibliotheek onderhouden door één persoon in zijn of haar vrije tijd. Dat is een risico in de toeleveringsketen, en het eerlijke antwoord is te helpen de last te dragen. Identificeer je meest kritieke afhankelijkheden uit je bill of materials, vind degene met een dunne beheerdersbasis en kies voor elk een respons: sponsor de beheerder direct, draag engineeringtijd bij, treed toe tot een stichting die het project financiert of bereid je als laatste redmiddel voor te forken of te vervangen. De commons financieren is goedkoper dan de noodsituatie die volgt op haar instorting, en het houdt de componenten waarop je leunt gezond en in een richting die je kunt beïnvloeden.

Stel bijdragebeleid vast dat snel goedkeurt

Een bijdragebeleid bestaat om snel ja te zeggen, niet om langzaam nee te zeggen. Leg uit wat een engineer mag bijdragen zonder te vragen (bugfixes, documentatie, kleine functies voor projecten die je al gebruikt), wat een lichte controle nodig heeft (alles wat een onderscheidende zaak of octrooi raakt) en hoe intellectueel eigendom en bijdrageovereenkomsten eenmaal, centraal worden afgehandeld, in plaats van per bijdrage. Automatiseer de saaie delen: licentiecontroles, een vooraf getekende zakelijke bijdrageovereenkomst en een bot die de zeldzame inzending markeert die menselijke ogen nodig heeft. Meet tijd-tot-goedkeuring en behandel een trage wachtrij als bug in het beleid.

Afwegingen: voor- en nadelen

Aanpak	Voordelen	Nadelen
Centrale OSPO	Consistent beleid, diepe expertise, helder eigenaarschap	Kan een knelpunt worden als ze alleen poort bewaakt en nooit mogelijk maakt
Gefedereerde OSPO (kampioenen in teams)	Schaalt, houdt beslissingen dicht bij engineers	Vraagt sterke coördinatie of beleid drijft uiteen
Bijdragen aan upstream	Verwijdert belasting van eigen patches, koopt invloed, helpt werven	Doorlopende inspanning, IE-review, werk op het schema van een ander
Eigen forks meedragen	Volledige controle, uitleveren op je eigen tijdlijn	Permanente onderhoudsbelasting, drijft af van beveiligingsreparaties upstream
Je eigen project uitbrengen	Ecosysteem, reputatie, gedeeld onderhoud	Echte rentmeesterschapskosten. Verlating schaadt reputatie
Beheerders financieren	Beschermt kritieke afhankelijkheden, koopt goodwill	Directe kosten, en kiezen wie te financieren is politiek
Geen OSPO (ad hoc)	Nul opzetkosten	Onzichtbare juridische, beveiligings- en duurzaamheidsschuld

De centrale spanning is tussen controle en mogelijk maken. Een OSPO die elke afhankelijkheid en elke bijdrage met de hand beoordeelt voelt veilig, maar wordt het ding waar engineers omheen werken, wat de onzichtbare schaduwafhankelijkheden produceert die je wilde voorkomen. Een OSPO die alleen opgewekte richtlijnen publiceert zonder geautomatiseerde afdwinging wordt genegeerd op het moment dat een deadline dreigt. De oplossing is dezelfde die door hoofdstuk 10.3 loopt: automatiseer het gangbare geval zodat het conforme pad het snelste pad is en reserveer menselijk oordeel voor het werkelijk nieuwe. Krijg die balans goed en het kantoor is een krachtvermenigvuldiger. Krijg haar in beide richtingen fout en het is een rem of decoratie.

Vragen om met je team te bespreken

Wie bezit vandaag je relatie met open source, en zou die persoon morgen een moeilijke vraag kunnen beantwoorden? Als de advocaten van een potentiële overnemer om je licentie-inventaris vroegen, of een journalist vroeg welke onderhoudsloze bibliotheek in je betaalpad zit, is er dan een naam aan het antwoord verbonden? Voor de meeste organisaties is het eerlijke antwoord “niemand”, wat betekent dat elke engineer stilletjes beleid maakt en niemand verantwoordelijk is voor de som. Neem het bewijs mee naar de vergadering: probeer de goedgekeurde licentielijst te produceren, de software bill of materials en de persoon die een copyleftvraag zou afhandelen tijdens due diligence. Als die artefacten niet bestaan of naar niemand wijzen, heb je je eerste OSPO-taak gevonden. De beslissing is niet of je de functie hebt maar wie haar bezit en welk mandaat die draagt, zelfs als het kantoor één persoon voor één dag per week is.
Draag je eigen patches mee die je kon upstreamen, en wat kost je dat? Veel teams onderhouden stilletjes een stapel lokale wijzigingen tegen hun afhankelijkheden, ze bij elke upgrade met de hand opnieuw toepassend en de samenvoegpijn absorberend alsof het een natuurwet is. Elk van die patches is een terugkerende belasting, en elk is kandidaat om terug te dragen zodat de belasting verdwijnt. Neem de specifieke gegevens mee: som de forks en lokale patches op die je build werkelijk draagt, schat de engineeringuren die elk per jaar kost en noteer welke upstreamprojecten de wijziging waarschijnlijk zouden accepteren. De concurrerende overweging is echt, aangezien upstreamen nu inspanning kost en op het schema van de beheerder loopt, maar de vergelijking is met de patchbelasting voor altijd betalen. Het antwoord moet “we passen hem gewoon altijd opnieuw toe” omzetten in een bewuste keuze, met een bijdragepad snel genoeg dat engineers het gebruiken.
Welke afhankelijkheid zou het meeste pijn doen als haar beheerder wegliep, en wat ga je eraan doen? Ergens in je stack zit een component die een omzet- of missiekritieke service zou stoppen als ze brak, onderhouden door een persoon of een handvol mensen die je nooit hebt gefinancierd of bedankt. De commons voelt gratis tot het moment dat ze dat niet meer is, en de dure versie van die les is een wedloop na verlating of een ongepatchte kwetsbaarheid. Neem je bill of materials mee en rangschik afhankelijkheden naar schadezone, noteer dan het aantal beheerders en de financieringsstatus van de top paar. Besluit voor elke kritieke, dun bemande vooraf of je sponsort, tijd bijdraagt, toetreedt tot een stichting of je voorbereidt te vervangen. Dat zet een latente single point of failure om in een beheerde relatie, gehouden aan dezelfde maatstaf als elk ander operationeel risico (hoofdstuk 2.18).
Ben je, voordat je het volgende interne hulpmiddel open source maakt, klaar het jaren te beheren, of lever je een lancering en een uiteindelijke verontschuldiging? Een publieke release is een doorlopende toezegging: een issuetracker die iemand moet triageren, een beveiligingsinbox die iemand moet bewaken en een naam die iemand moet verdedigen. Teams grijpen naar open source maken om te werven of goodwill, en ontdekken dan dat een verlaten project met verouderde issues de reputatie schaadt die ze hoopten op te bouwen, meer dan niets uitleveren zou hebben gedaan. Neem het bewijs mee: som de projecten op die je al hebt uitgebracht en toon voor elk de leeftijd van open issues, of een benoemde beheerder begrote uren heeft, of het een governancemodel, een geregistreerd handelsmerk en een beleid voor gecoördineerde openbaarmaking heeft en of de code een commodity is die het delen waard is of een onderscheidende zaak die je gesloten moet houden (hoofdstuk 10.12). De concurrerende overweging is dat echt rentmeesterschap engineeringtijd kost die je aan het product kon besteden, dus de eerlijke keuze is vaak minder dingen uitbrengen en ze goed beheren. Voor een onderneming betekent dit juridische en merkreview vóór de lancering. Voor de overheid betekent het dat het handelsmerk, het openbaarmakingskanaal en het uitzonderingsproces van publiceren-als-standaard zijn geregeld voordat de repository publiek gaat.
Hoe lang duurt het een engineer werkelijk om een afhankelijkheid goedgekeurd of een bijdrage vrijgegeven te krijgen, en is dat trager dan om je heen werken? Een open-sourcebeleid concurreert direct met de snelste omweg die een engineer kan vinden, en elk proces trager dan code kopiëren wordt omzeild, wat de onzichtbare schaduwafhankelijkheden produceert die het kantoor moest voorkomen. De spanning is controle tegenover mogelijk maken: elke handmatige review voegt een auditspoor toe en vangt het zeldzame echte probleem, maar voegt ook latentie toe die het mediane geval van het conforme pad duwt. Neem de getallen mee naar de vergadering: de gemeten tijd-tot-goedkeuring voor een standaardafhankelijkheid en een standaardbijdrage, het aandeel beslissingen automatisch afgehandeld tegenover door een mens en het aantal uitzonderingen dat vorig kwartaal werkelijk oordeel nodig had. In een onderneming met honderden engineers die elk dagelijks kleine beslissingen nemen wordt een wachtrij van twee dagen stilletjes duizenden omzeilde reviews. Bij de overheid botst dezelfde latentie met aanbestedings- en auditverplichtingen die het papieren spoor eisen dat de omweg overslaat, dus de oplossing is het gangbare geval automatiseren in plaats van een grotere poort te bemannen.
Welke interne projecten zouden het meest baat hebben bij InnerSource, en wat belet een ander team vandaag je een pull request te sturen? De praktijken die open source laten werken (publieke repositories, bijdragegidsen, review op verdienste, een lage drempel voor een eerste patch) lonen achter de firewall door silo’s af te breken, hergebruik te verspreiden en mensen te trainen in precies de workflow die ze zullen gebruiken om extern bij te dragen. De concurrerende overweging is dat een intern project openen een bijdragegids vraagt, reservereviewcapaciteit en een beslissing over welke code beperkt moet blijven om beveiligings- of wettelijke redenen. Neem de specifieke gegevens mee: noem de waardevolle gedeelde bibliotheken, noteer welke al een interne bijdragegids publiceren en beschrijf hoe een pull request tussen teams vandaag wordt afgehandeld, of het wordt verwelkomd of verloren in een wachtrij. Voor een onderneming wordt de opbrengst gemeten in vermeden dubbele interne bouw over veel teams. Voor de overheid strekt dezelfde gewoonte zich uit over agentschapsgrenzen als hergebruik tussen instanties, zodat publiceren-als-standaard en gedeelde componenten dubbele publieke uitgaven verminderen in plaats van vermenigvuldigen.

Sectorperspectief

Startup. Geef het kantoor aan één benoemde engineer voor een paar uur per week met een handvest van één pagina, geen comité. Kies standaard voor permissieve licenties met een scanner in de pijplijn, upstream alleen de handvol eigen patches die bij elke upgrade echt pijn doen en zet een kleine maandelijkse sponsoring op voor de bibliotheek met één beheerder zonder welke je werkelijk niet kunt leven. Snelheid telt hier meer dan dekking: een conform pad sneller dan code kopiëren verslaat een grondig beleid dat niemand volgt.

Kleinbedrijf. Je zult geen speciale OSPO bemannen, dus koop het vermogen ingebed in tools die je al draait: een scanner die licentie- en kwetsbaarheidsproblemen markeert en een gecureerde catalogus van vooraf gecontroleerde componenten. Formuleer het werk als hygiëne van licentienaleving en afhankelijkheidsgezondheid in plaats van een programma: weet wat er in je software bill of materials staat, weet wat elke licentie verplicht en weet welke afhankelijkheid met één beheerder pijn zou doen als ze verdween. Geef de voorkeur aan scannen en catalogiseren kopen boven het zelf bouwen.

Grote onderneming. Draai een klein centraal kantoor plus een gefedereerd netwerk van kampioenen ingebed in productteams, zodat beleid consistent blijft terwijl beslissingen dicht bij engineers blijven. Automatiseer scannen op licenties, kwetsbaarheden en export, dek elke engineer met een vooraf goedgekeurde bijdrageovereenkomst en volg tijd-tot-goedkeuring als gerapporteerde statistiek. Financier de stichtingen achter je kritieke afhankelijkheden, draai InnerSource over veel repositories en beheer het hele landschap als portfolio met gezondheids- en betrokkenheidsstatistieken in plaats van een kluwen individuele beslissingen.

Overheid. Opereer onder open-source-als-standaard en public-money-public-code: publiceer nieuwe diensten in een publieke repository tenzij een gedocumenteerde beveiligings- of privacyuitzondering geldt. Draai een catalogus over de hele overheid zodat teams hergebruiken voordat ze bouwen, schrijf open-source- en open-standaardeneisen in de inkoop zodat leveranciers herbruikbare code opleveren met behouden rechten en handel gecoördineerde openbaarmaking af voor wat je publiceert. Financier het onderhoud van gedeelde bibliotheken waarvan meerdere agentschappen afhangen, zodat geen enkel team stilletjes infrastructuur bezit waarop de hele overheid leunt.

Voorbeelden

Startup. Een startup van twintig personen maakt haar leidende platformengineer de deeltijd-OSPO-eigenaar met een handvest van één pagina. Ze stelt een eenvoudig gebruiksbeleid in (permissieve licenties vooraf goedgekeurd, copyleft beoordeeld, scanner in de pijplijn), en merkt dat het team drie eigen patches meedraagt tegen een open-sourcewachtrijbibliotheek, bij elke upgrade pijnlijk opnieuw toegepast. Ze upstreamt alle drie. Twee worden binnen een maand geaccepteerd, wat de upgradebelasting voorgoed verwijdert. Ze maakt één klein intern hulpmiddel open source met een echte README, een licentie en een beveiligingscontact, vooral om engineers aan te trekken, en zet een maandelijkse sponsoring op voor de parser met één beheerder waarvan het product afhangt. Niets hiervan vraagt formatie, alleen een benoemde eigenaar en een helder mandaat.

Grote onderneming. Een wereldwijde bank draait een centrale OSPO van zes mensen plus een gefedereerd netwerk van open-sourcekampioenen ingebed in elke productgroep. Het centrale team bezit beleid, het geautomatiseerde scannen op licenties en exportcompliance en de bijdrageovereenkomst die elke engineer vanaf dag één dekt. De kampioenen handelen lokale review af en coachen hun teams in bijdragen. De bank financiert verschillende stichtingen wier projecten haar handelssystemen onderbouwen, draagt reparaties bij aan upstream bij een veelgebruikt dataframework zodat ze ophoudt een fork te onderhouden en draait InnerSource over tweehonderd interne repositories zodat elk team een pull request naar elk ander kan sturen. De tijd-tot-goedkeuring voor een standaardbijdrage is minder dan twee dagen, bijgehouden als statistiek die de OSPO elk kwartaal rapporteert.

Overheid. Een nationaal digitaal agentschap opereert onder een mandaat van “open source als standaard” en public-money-public-code. Haar OSPO publiceert nieuwe diensten in een publieke repository tenzij een gedocumenteerde uitzondering voor beveiliging of privacy geldt, draait een catalogus over de hele overheid zodat agentschappen code hergebruiken voordat ze bouwen en schrijft open-source- en open-standaardeneisen in de inkoop zodat leveranciers herbruikbare, goed gedocumenteerde code opleveren waarbij de overheid de rechten houdt. Het kantoor handelt ook gecoördineerde beveiligingsopenbaarmaking af voor de code die het publiceert en financiert het onderhoud van een gedeelde identiteitsbibliotheek waarvan nu meerdere agentschappen afhangen, zodat geen enkel team stilletjes een component bezit waarop de hele overheid leunt.

Zakelijke onderbouwing: motivatie, ROI en TCO

Het duidelijkste rendement is het elimineren van vermijdbare, dure verrassingen. Onbeheerde open source produceert crises die op hun eigen schema arriveren: een copyleftschending opgemerkt tijdens due diligence bij een overname, een noodmigratie weg van een dode component, een inbreuk herleid tot een afhankelijkheid die geen inventaris vermeldde. Een OSPO zet die gebeurtenissen met lage kans en hoge kosten om in gestaag, begroot werk. Leg daar de terugkerende besparingen van upstreamen overheen: elke eigen patch die je afschaft houdt op elke toekomstige upgrade te belasten, en over een groot landschap loopt dat samengesteld op tot echte engineeringcapaciteit teruggegeven aan productwerk.

Op het grootboek van total cost of ownership is het kantoor goedkoop vergeleken met wat het beschermt. De kosten zijn een klein team, wat scan- en catalogustooling en bescheiden financiering van beheerders. Zet dat tegenover de kosten van het niet hebben: juridische aansprakelijkheid, mislukte of vertraagde due diligence, beveiligingsincidenten, dubbele interne bouw van dingen die al als open source bestaan en de langzame bloeding van forks die niemand koos te houden. Er zijn ook opwaartse rendementen die moeilijker te prijzen maar echt zijn: invloed op de richting van componenten waarvan je afhangt, een wervings- en reputatievoordeel van een geloofwaardige open-sourcepresentie en snellere oplevering omdat engineers hergebruiken in plaats van opnieuw bouwen. Wanneer je de zaak voor leiderschap maakt, formuleer de OSPO als beheer van de toeleveringsketen voor het merendeel van je codebasis, met een strategisch dividend erbovenop. Voeg bij de overheid de compliancedimensie toe, aangezien openheid vaak voorgeschreven is en het goed doen zowel niet-naleving als dubbele publieke uitgaven vermijdt.

Antipatronen en valkuilen

De OSPO als poort. Een kantoor dat alleen beoordeelt en blokkeert, nooit mogelijk maakt, wordt omzeild en produceert de schaduwafhankelijkheden die het moest voorkomen.
Bijdragetoneel. Een open-sourcestrategie aankondigen terwijl het goedkeuringsproces zo traag is dat niemand werkelijk bijdraagt.
De verlaten release. Een project publiceren met een lanceringsblog en dan nooit een issue triageren, wat je reputatie meer schaadt dan stilte zou doen.
Forken en vergeten. Een afhankelijkheid forken voor één reparatie en haar dan voor altijd meedragen, afdrijvend van beveiligingspatches upstream.
Meeliften op kwetsbare beheerders. Afhangen van een kritieke bibliotheek met één beheerder en de persoon erachter nooit financieren, bedanken of helpen.
Handelsmerkverwaarlozing. Een project uitbrengen zonder de naam te beschermen en dan toekijken hoe een fork of leverancier op je reputatie handelt.
Eigenaarschap alleen bij juridische zaken. De OSPO volledig in juridische zaken huisvesten zodat haar richtlijnen geen engineeringgeloofwaardigheid dragen en teams ze negeren.
IJdele statistieken. Sterren en persvermeldingen tellen in plaats van afhankelijkheidsgezondheid, tijd-tot-goedkeuring en afgeschafte eigen patches.

Volwassenheidsmodel

Niveau 1, Initiëren: Engineers voegen open source toe, patchen en publiceren af en toe zonder beleid en zonder eigenaar. Gebruik, bijdragen en uitbrengen zijn reactief en ad hoc, gedreven door individueel initiatief. Eigen forks stapelen ongemerkt op, niemand financiert enig upstreamproject en niemand zou een licentievraag tijdens due diligence kunnen beantwoorden.
Niveau 2, Ontwikkelen: Basispraktijken verschijnen maar variëren per team. Een ruw gebruiksbeleid en goedgekeurde licentielijst bestaan en iemand is losjes verantwoordelijk, maar bijdragen is traag en geval voor geval en sommige groepen doen veel meer dan andere. Een paar kritieke afhankelijkheden zijn bekend, maar duurzaamheid, releases en rentmeesterschap blijven inconsistent.
Niveau 3, Standaardiseren: Een gecharterde OSPO bezit gebruik, bijdragen, uitbrengen en gemeenschap, en de praktijken zijn gedocumenteerd en organisatiebreed afgedwongen. Scannen en een software bill of materials zijn geautomatiseerd, een vooraf goedgekeurde bijdrageovereenkomst en een snel goedkeuringspad bestaan, uitgebrachte projecten dragen echte governance, handelsmerken en beveiligingsbeleid, en InnerSource verspreidt zich. Overheidsteams publiceren standaard.
Niveau 4, Beheersen: De open-sourcefunctie wordt gemeten en beheerst tegen uitgangswaarden. Tijd-tot-goedkeuring wordt gevolgd tegen een doel, bijdragevolume en upstream-acceptatiepercentage worden gerapporteerd, dashboards voor afhankelijkheidsgezondheid en aantal beheerders markeren single points of failure, dekking met gefinancierde beheerders van de afhankelijkheden met het hoogste risico wordt bewaakt en de inventaris van eigen patches en forks daalt kwartaal na kwartaal. Uitgebrachte projecten hebben gemeten responstijden op issues, uitzonderingen worden volgens ritme beoordeeld en ijdele statistieken als sterren worden laten vallen ten gunste van deze.
Niveau 5, Orkestreren: Open source is een beheerd strategisch vermogen, geïntegreerd met engineering-, juridische, beveiligings- en inkoopplanning en continu aangepast. Bijdragen is routine, kritieke beheerders en stichtingen worden gefinancierd, de organisatie beheert goed gedraaide projecten en stuurt de ecosystemen waarvan ze afhangt, en InnerSource is de norm. Betrokkenheids- en gezondheidsstatistieken voeden continue verbetering, en het portfolio wordt herbalanceerd naarmate afhankelijkheden, risico’s en mandaten verschuiven.

Ideeën voor discussie

Waar ligt de lijn tussen een OSPO die mogelijk maakt en een die poort bewaakt, en hoe zou je van buitenaf weten welke je hebt gebouwd?
Welke van je eigen patches of forks draag je uit gewoonte in plaats van noodzaak mee, en wat zou nodig zijn om de top drie te upstreamen?
Hoe moet je beslissen welke beheerders en stichtingen te financieren wanneer de lijst kritieke afhankelijkheden langer is dan het budget?
Wat zou er werkelijk veranderen in je volgende release als je haar met echte governance, een handelsmerk en een beleid voor gecoördineerde openbaarmaking vanaf dag één moest publiceren?
Wat is voor lezers in de publieke sector een verdedigbaar proces om code vrij te stellen van publiceren-als-standaard zonder het principe stilletjes uit te hollen?
Welke interne bibliotheken zouden het meest baat hebben bij InnerSource, en wat belet een ander team vandaag je een pull request te sturen?

Belangrijkste inzichten

Een OSPO bezit de hele relatie met open source: verantwoord gebruiken, bijdragen aan upstream, je eigen projecten uitbrengen en de beheerders ondersteunen van wie je afhangt.
Bijdragen aan upstream is strategie, geen liefdadigheid. Het verwijdert de terugkerende belasting van eigen patches, koopt invloed op de richting en helpt werven.
Maak het conforme pad het snelste pad via automatisering en curatie, zodat het kantoor engineers mogelijk maakt in plaats van ze te bewaken.
Breng je eigen projecten alleen uit met echte governance, een gekozen licentie, een beschermd handelsmerk en gecoördineerde beveiligingsopenbaarmaking, of breng ze helemaal niet uit.
Financier en help de kritieke beheerders waarop je productiesysteem rust, want de commons is niet zelfvoorzienend.
Pas InnerSource toe om open-sourcesamenwerking binnen het bedrijf te brengen, en kies bij de overheid standaard voor open, publiceer standaard en hergebruik voordat je bouwt.

Referenties en verder lezen

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