10.18 Bureau de programme de code source ouvert (OSPO) et contribution en amont

Vue d’ensemble et motivation

Votre organisation fonctionne déjà sur du logiciel à code source ouvert : les systèmes d’exploitation, langages, bases de données, et bibliothèques qui portent votre produit sont surtout écrits par des gens qui ne travaillent pas pour vous. Le chapitre 10.3 couvre les marchés publics et la conformité de licence, et le chapitre 10.12 couvre la décision ouvert-contre-fermé. Ce chapitre parle de la fonction qui rend tout cela cohérent : un bureau de programme de code source ouvert (OSPO), l’équipe qui possède comment l’entreprise consomme, contribue à, et publie du code source ouvert. Un OSPO est le centre de gravité pour une relation qui est autrement répartie à travers chaque ingénieur qui tape import.

La plupart des organisations entrent dans le code source ouvert une dépendance à la fois, puis découvrent l’exposition accumulée d’un coup : une question de licence pendant la diligence raisonnable d’acquisition, une bibliothèque critique avec un mainteneur épuisé, un avis de sécurité dans du code que personne ne savait qu’il livrait. Un OSPO transforme cette ruée en une capacité gérée. Il fixe une politique de consommation qui habilite plutôt que bloque, il décide quand contribuer en amont sert l’affaire, il gère les projets que vous publiez, et il applique la collaboration ouverte à l’intérieur de l’entreprise à travers l’InnerSource. C’est une fonction stratégique, connectée à vos valeurs d’ingénierie logicielle (chapitre 1.1), pas une case de conformité.

Pour les entreprises, le moteur est l’échelle : des milliers de dépendances, des obligations d’exportation et de licence à travers les juridictions, et des centaines d’ingénieurs qui prennent chacun de petites décisions de code source ouvert quotidiennement. Un bureau unique donne à cette étendue une épine dorsale. Pour le gouvernement, le moteur est la politique et la confiance publique. « Code source ouvert par défaut » et « argent public, code public » sont de plus en plus la loi, donc les organismes publics ont besoin de quelqu’un qui peut publier du code en sécurité, réutiliser à travers les agences, et tenir les fournisseurs aux normes ouvertes. Dans les deux contextes, l’OSPO se rentabilise en convertissant un risque invisible et non tarifé en travail délibéré et budgété.

Principes clés

Le code source ouvert est une relation à double sens, pas un entrepôt gratuit. Vous consommez, vous contribuez, et vous publiez, et un OSPO possède les trois.
La contribution est de la stratégie, pas de la charité. Remonter en amont réduit le coût de porter des correctifs privés et vous achète de l’influence.
Habilitez le chemin rapide, ne gardez pas la porte. Une politique plus lente que copier du code sera ignorée, donc faites du chemin conforme le plus rapide.
Financez les mainteneurs dont vous dépendez. Le commun n’est pas autoportant, et votre bibliothèque la plus critique peut avoir un seul auteur non payé.
Gérez ce que vous publiez, ou ne le publiez pas. Un projet abandonné nuit à votre réputation plus qu’aucun projet ne le ferait jamais.
Mesurez l’engagement pour pouvoir l’améliorer. Comptez les contributions, la santé des dépendances, et le temps jusqu’à l’approbation, pas les communiqués de presse.
Dans le gouvernement, préférez par défaut l’ouvert et publiez par défaut. L’ouverture est la norme ; la fermeture est l’exception documentée.

Recommandations

Ériger un OSPO dimensionné à votre réalité

Vous n’avez pas besoin d’une grande équipe pour commencer. Dans une jeune pousse, un OSPO peut être un ingénieur avec un mandat écrit et quelques heures par semaine. Dans une entreprise, c’est un petit groupe central plus un réseau fédéré de champions intégrés dans les équipes produit. Peu importe la taille, donnez-lui une charte claire couvrant quatre responsabilités : politique de consommation et conformité, contribution en amont, publication et gestion de vos propres projets, et relations de communauté et de financement. Placez-le là où il peut voir à la fois l’ingénierie et le juridique, rapportant souvent au CTO ou un VP d’ingénierie avec une ligne pointillée vers le juridique et la sécurité. Le mode d’échec est un OSPO qui vit entièrement à l’intérieur du juridique et devient un frein ; le correctif est de le doter en ingénieurs qui livrent, pour que ses conseils portent une crédibilité auprès des équipes qu’il sert.

Consommer de façon responsable, et faire du chemin sûr le chemin facile

La consommation est où la plupart du risque entre, donc rendez le bon comportement sans effort. Fournissez un catalogue interne sélectionné de composants prévérifiés, un scan de licence et de vulnérabilité automatisé dans le pipeline, et des défauts clairs qu’un développeur peut suivre sans déposer un ticket. Appuyez-vous sur la discipline de licence du chapitre 10.3 et les pratiques de chaîne d’approvisionnement et de santé de dépendance du chapitre 2.18 : épinglez les versions, générez une nomenclature logicielle, surveillez la chaîne d’approvisionnement logicielle pour les paquets compromis ou abandonnés, et suivez la fin de vie avant qu’elle ne force une migration. Le travail de l’OSPO n’est pas d’approuver chaque dépendance à la main. C’est de construire les garde-fous pour que quatre-vingt-quinze pour cent des choix soient sûrs automatiquement et seuls les cas véritablement inhabituels atteignent un humain.

Contribuer en amont parce que cela paie, pas parce que c’est gentil

Traitez la contribution en amont comme une décision économique. Chaque correctif privé que vous portez contre une dépendance est une taxe que vous payez à chaque mise à niveau, pour toujours, jusqu’à ce que le changement atterrisse en amont ou que la bifurcation diverge tellement que vous la possédez entièrement. Contribuer le correctif en retour supprime cette taxe. Remonter en amont achète aussi de l’influence sur la direction, pour que la feuille de route d’un composant dont vous dépendez plie vers vos besoins, et cela signale la compétence aux ingénieurs que vous voulez embaucher. Donnez à vos développeurs un chemin rapide et documenté : un accord de licence de contributeur préclarifié ou un certificat d’origine de développeur, une approbation légère qui confirme que le changement est sûr à partager, et du temps de gestion budgété pour le travail. Quand l’alternative est de maintenir une bifurcation permanente d’un projet que vous ne contrôlez pas, contribuer en retour est presque toujours moins cher.

Publier vos propres projets avec une vraie gouvernance

Quand vous ouvrez en code source un logiciel que vous avez construit, faites-le délibérément ou pas du tout. Décidez d’abord si le code est une commodité qui vaut la peine d’être partagée ou un différenciateur qui vaut la peine d’être gardé fermé, en utilisant le raisonnement du chapitre 10.12. Si vous publiez, choisissez une licence qui correspond à votre intention (permissive pour maximiser l’adoption, copyleft pour garder l’écosystème réciproque), documentez qui décide quoi à travers un modèle de gouvernance écrit, et enregistrez la marque sur le nom du projet pour pouvoir la protéger contre l’abus tout en gardant le code libre. Engagez-vous à une vraie gestion : un traqueur de problèmes public, un guide de contribution, un code de conduite, et une politique de sécurité avec divulgation coordonnée pour que les rapporteurs sachent comment vous atteindre (chapitre 4.2). Nommez un mainteneur et budgétez son temps. Un projet que vous lancez en fanfare et abandonnez en un an nuit davantage à votre réputation que celui que vous n’avez jamais livré.

Appliquer l’InnerSource pour collaborer à l’intérieur de l’entreprise

Les habitudes qui font fonctionner le code source ouvert (dépôts publics, guides de contribution clairs, revue par mérite, faibles barrières pour un premier correctif) fonctionnent tout aussi bien derrière le pare-feu. L’InnerSource signifie que tout ingénieur peut trouver, utiliser, et améliorer tout projet interne, envoyant une demande de tirage à travers les frontières d’équipe au lieu de déposer un ticket et d’attendre. Cela brise les silos, répand la réutilisation de code, et forme vos gens au flux de travail exact qu’ils utiliseront quand ils contribueront externement. L’OSPO est le foyer naturel pour l’InnerSource parce qu’il possède déjà l’outillage et le livre de jeu culturel. Commencez avec quelques bibliothèques partagées à haute valeur, publiez leurs guides de contribution en interne, et récompensez les équipes qui acceptent gracieusement les correctifs externes.

Financer et soutenir les mainteneurs dont vous dépendez

Votre système de production peut reposer sur une bibliothèque maintenue par une personne pendant son temps libre. C’est un risque de chaîne d’approvisionnement, et la réponse honnête est d’aider à porter la charge. Identifiez vos dépendances les plus critiques depuis votre nomenclature, trouvez celles avec une base de mainteneur mince, et choisissez une réponse pour chacune : parrainez directement le mainteneur, contribuez du temps d’ingénierie, rejoignez une fondation qui finance le projet, ou, en dernier recours, préparez-vous à bifurquer ou remplacer. Financer le commun est moins cher que l’urgence qui suit son effondrement, et cela garde les composants dont vous dépendez sains et se déplaçant dans une direction que vous pouvez influencer.

Fixer une politique de contribution qui approuve rapidement

Une politique de contribution existe pour dire oui rapidement, pas pour dire non lentement. Précisez ce qu’un ingénieur peut contribuer sans demander (correctifs de bug, documentation, petites fonctionnalités aux projets que vous utilisez déjà), ce qui a besoin d’une vérification légère (tout ce qui touche un différenciateur ou un brevet), et comment la propriété intellectuelle et les accords de contributeur sont gérés une fois, centralement, plutôt que par contribution. Automatisez les parties ennuyeuses : vérifications de licence, un accord de contributeur d’entreprise présigné, et un robot qui signale la rare soumission ayant besoin d’yeux humains. Mesurez le temps jusqu’à l’approbation et traitez une file lente comme un bug dans la politique.

Compromis : avantages et inconvénients

Approche	Avantages	Inconvénients
OSPO central	Politique cohérente, expertise profonde, propriété claire	Peut devenir un goulot d’étranglement s’il ne fait que conditionner et n’habilite jamais
OSPO fédéré (champions dans les équipes)	Passe à l’échelle, garde les décisions proches des ingénieurs	A besoin d’une coordination forte sinon la politique dérive
Contribuer en amont	Supprime la taxe de correctif privé, achète de l’influence, aide le recrutement	Effort continu, revue de PI, travail sur le calendrier de quelqu’un d’autre
Porter des bifurcations privées	Contrôle complet, livrer sur votre calendrier	Taxe de maintenance permanente, dérive des correctifs de sécurité en amont
Publier votre propre projet	Écosystème, réputation, maintenance partagée	Vrai coût de gestion ; l’abandon nuit à la réputation
Financer les mainteneurs	Protège les dépendances critiques, achète la bonne volonté	Coût direct, et choisir qui financer est politique
Aucun OSPO (ad hoc)	Coût de mise en place nul	Dette légale, de sécurité, et de durabilité invisible

La tension centrale est entre le contrôle et l’habilitation. Un OSPO qui révise chaque dépendance et chaque contribution à la main se sent sûr, mais il devient la chose que les ingénieurs contournent, ce qui produit les dépendances fantômes invisibles que vous essayiez de prévenir. Un OSPO qui publie seulement des directives joyeuses sans aucune application automatisée est ignoré au moment où une échéance approche. La résolution est la même que celle qui traverse le chapitre 10.3 : automatisez le cas commun pour que le chemin conforme soit le chemin le plus rapide, et réservez le jugement humain pour le véritablement nouveau. Obtenez cet équilibre correct et le bureau est un multiplicateur de force ; trompez-vous dans une direction ou l’autre et c’est soit un frein soit une décoration.

Questions à discuter avec votre équipe

Qui possède votre relation avec le code source ouvert aujourd’hui, et pourrait-il répondre à une question difficile demain ? Si les avocats d’un acquéreur potentiel demandaient votre inventaire de licence, ou qu’un journaliste demandait quelle bibliothèque non maintenue se trouve dans votre chemin de paiement, y a-t-il un nom attaché à la réponse ? Pour la plupart des organisations, la réponse honnête est « personne », ce qui signifie que chaque ingénieur fait silencieusement de la politique et personne n’est responsable de la somme. Apportez la preuve à la réunion : essayez de produire la liste de licences approuvées, la nomenclature logicielle, et la personne qui répondrait à une question de copyleft pendant la diligence raisonnable. Si ces artefacts n’existent pas ou ne pointent vers personne, vous avez trouvé votre première tâche d’OSPO. La décision à prendre n’est pas si avoir la fonction mais qui la possède et quel mandat elle porte, même si le bureau est une personne pour un jour par semaine.
Portez-vous des correctifs privés que vous pourriez remonter en amont, et qu’est-ce que cela vous coûte ? De nombreuses équipes maintiennent une pile silencieuse de modifications locales contre leurs dépendances, les réappliquant à la main à chaque mise à niveau et absorbant la douleur de fusion comme si c’était une loi de la nature. Chacun de ces correctifs est une taxe récurrente, et chacun est un candidat à contribuer en retour pour que la taxe disparaisse. Apportez les spécificités : listez les bifurcations et correctifs locaux que votre construction porte réellement, estimez les heures d’ingénierie que chacun coûte par an, et notez quels projets en amont accepteraient probablement le changement. La considération concurrente est réelle, puisque remonter en amont prend de l’effort maintenant et fonctionne sur le calendrier du mainteneur, mais la comparaison est contre payer la taxe de correctif pour toujours. La réponse devrait transformer « nous le réappliquons toujours simplement » en un choix délibéré, avec un chemin de contribution assez rapide pour que les ingénieurs l’utilisent.
Quelle dépendance ferait le plus mal si son mainteneur partait, et que ferez-vous à ce sujet ? Quelque part dans votre pile se trouve un composant qui arrêterait un service critique pour le revenu ou la mission s’il cassait, maintenu par une personne ou une poignée de personnes que vous n’avez jamais financées ou remerciées. Le commun se sent gratuit jusqu’au moment où il ne l’est pas, et la version coûteuse de cette leçon est une ruée après l’abandon ou une vulnérabilité non corrigée. Apportez votre nomenclature et classez les dépendances par rayon d’explosion, puis notez le compte de mainteneurs et le statut de financement des quelques principales. Pour chaque critique et minces en personnel, décidez à l’avance si vous parrainerez, contribuerez du temps, rejoindrez une fondation, ou préparerez le remplacement. Cela convertit un point unique de défaillance latent en une relation gérée, tenue au même standard que tout autre risque opérationnel (chapitre 2.18).
Avant d’ouvrir en code source le prochain outil interne, êtes-vous prêt à le gérer pendant des années, ou livrez-vous un lancement et une excuse éventuelle ? Une publication publique est un engagement permanent : un traqueur de problèmes que quelqu’un doit trier, une boîte de sécurité que quelqu’un doit surveiller, et un nom que quelqu’un doit défendre. Les équipes atteignent pour ouvrir en code source pour aider le recrutement ou la bonne volonté, puis découvrent qu’un projet abandonné avec des problèmes périmés nuit à la réputation qu’elles espéraient construire, plus que ne rien livrer ne l’aurait fait. Apportez la preuve : listez les projets que vous avez déjà publiés, et pour chacun montrez l’âge de problème ouvert, si un mainteneur nommé a des heures budgétées, s’il a un modèle de gouvernance, une marque enregistrée, et une politique de divulgation coordonnée, et si le code est une commodité qui vaut la peine d’être partagée ou un différenciateur que vous devriez garder fermé (chapitre 10.12). La considération concurrente est qu’une vraie gestion coûte du temps d’ingénierie que vous pourriez dépenser sur le produit, donc le choix honnête est souvent de publier moins de choses et de bien les gérer. Pour une entreprise, cela signifie une revue juridique et de marque avant le lancement ; pour le gouvernement, cela signifie que la marque, le canal de divulgation, et le processus d’exemption de publication par défaut sont réglés avant que le dépôt ne devienne public.
Combien de temps faut-il réellement à un ingénieur pour faire approuver une dépendance ou faire nettoyer une contribution, et est-ce plus lent que de vous contourner ? Une politique de code source ouvert rivalise directement avec le contournement le plus rapide qu’un ingénieur peut trouver, et tout processus plus lent que copier le code est contourné, produisant les dépendances fantômes invisibles que le bureau était censé prévenir. La tension est contrôle contre habilitation : chaque revue manuelle ajoute une piste d’audit et attrape le rare vrai problème, mais elle ajoute aussi de la latence qui pousse le cas médian hors du chemin conforme. Apportez les chiffres à la réunion : le temps mesuré jusqu’à l’approbation pour une dépendance standard et une contribution standard, la part de décisions gérées automatiquement contre par un humain, et le compte d’exceptions qui avaient véritablement besoin de jugement le dernier trimestre. Dans une entreprise avec des centaines d’ingénieurs prenant chacun de petites décisions quotidiennement, une file de deux jours devient silencieusement des milliers de revues contournées ; dans le gouvernement, la même latence entre en collision avec les obligations de marchés publics et d’audit qui exigent la piste papier que le contournement saute, donc le correctif est d’automatiser le cas commun plutôt que de doter une porte plus grande.
Quels projets internes bénéficieraient le plus de l’InnerSource, et qu’est-ce qui empêche une autre équipe de vous envoyer une demande de tirage aujourd’hui ? Les pratiques qui font fonctionner le code source ouvert (dépôts publics, guides de contribution, revue par mérite, une barrière basse pour un premier correctif) rapportent derrière le pare-feu en brisant les silos, répandant la réutilisation, et formant les gens au flux de travail exact qu’ils utiliseront pour contribuer externement. La considération concurrente est qu’ouvrir un projet interne exige un guide de contribution, une capacité de revue de réserve, et une décision sur quel code doit rester restreint pour des raisons de sécurité ou réglementaires. Apportez les spécificités : nommez les bibliothèques partagées à haute valeur, notez lesquelles publient déjà un guide de contribution interne, et décrivez comment une demande de tirage inter-équipes est gérée aujourd’hui, si elle est bienvenue ou perdue dans une file. Pour une entreprise, le gain se mesure en constructions internes dupliquées évitées à travers de nombreuses équipes ; pour le gouvernement, la même habitude s’étend à travers les frontières d’agence comme réutilisation inter-agences, pour que la publication par défaut et les composants partagés réduisent la dépense publique dupliquée plutôt que de la multiplier.

Regard sectoriel

Jeune pousse. Donnez le bureau à un ingénieur nommé pour quelques heures par semaine avec une charte d’une page, pas un comité. Préférez par défaut les licences permissives avec un scanner dans le pipeline, remontez en amont seulement la poignée de correctifs privés qui font réellement mal à chaque mise à niveau, et mettez en place un petit parrainage mensuel pour la bibliothèque à mainteneur unique dont vous ne pouvez véritablement pas vous passer. La vitesse compte plus que la couverture ici : un chemin conforme plus rapide que copier le code bat une politique approfondie que personne ne suit.

Petite entreprise. Vous ne doterez pas un OSPO dédié, donc achetez la capacité intégrée dans les outils que vous exploitez déjà : un scanner qui signale les problèmes de licence et de vulnérabilité, et un catalogue sélectionné de composants prévérifiés. Cadrez le travail comme de l’hygiène de conformité de licence et de santé de dépendance plutôt qu’un programme : sachez ce qui est dans votre nomenclature, sachez ce que chaque licence oblige, et sachez quelle dépendance à mainteneur unique ferait mal si elle disparaissait. Préférez acheter le scan et la catalogisation plutôt que construire les vôtres.

Grande entreprise. Exploitez un petit bureau central plus un réseau fédéré de champions intégrés dans les équipes produit, pour que la politique reste cohérente tandis que les décisions restent proches des ingénieurs. Automatisez le scan de licence, vulnérabilité, et exportation, couvrez chaque ingénieur avec un accord de contributeur préclarifié, et suivez le temps jusqu’à l’approbation comme une métrique rapportée. Financez les fondations derrière vos dépendances critiques, exécutez l’InnerSource à travers de nombreux dépôts, et gérez tout le parc comme un portefeuille avec des métriques de santé et d’engagement plutôt qu’une dispersion de décisions individuelles.

Gouvernement. Opérez sous code-source-ouvert-par-défaut et argent-public-code-public : publiez les nouveaux services dans un dépôt public sauf si une exemption de sécurité ou de vie privée documentée s’applique. Exploitez un catalogue inter-agences pour que les équipes réutilisent avant de construire, écrivez des exigences de code source ouvert et de normes ouvertes dans les marchés publics pour que les fournisseurs livrent du code réutilisable avec les droits retenus, et gérez la divulgation coordonnée pour ce que vous publiez. Financez la maintenance des bibliothèques partagées dont plusieurs agences dépendent, pour qu’aucune équipe unique ne possède silencieusement l’infrastructure dont tout le gouvernement dépend.

Exemples

Jeune pousse. Une jeune pousse de vingt personnes fait de son ingénieur de plateforme principal le propriétaire OSPO à temps partiel avec une charte d’une page. Elle fixe une politique de consommation simple (licences permissives préapprouvées, copyleft révisé, scanner dans le pipeline), et remarque que l’équipe porte trois correctifs privés contre une bibliothèque de file d’attente à code source ouvert, réappliqués douloureusement à chaque mise à niveau. Elle les remonte tous les trois en amont ; deux sont acceptés en un mois, supprimant la taxe de mise à niveau pour de bon. Elle ouvre en code source un petit outil interne avec un vrai README, une licence, et un contact de sécurité, surtout pour attirer des ingénieurs, et met en place un parrainage mensuel pour l’analyseur à mainteneur unique dont le produit dépend. Rien de cela n’a besoin d’effectif, juste un propriétaire nommé et un mandat clair.

Grande entreprise. Une banque mondiale exploite un OSPO central de six personnes plus un réseau fédéré de champions de code source ouvert intégrés dans chaque groupe produit. L’équipe centrale possède la politique, le scan automatisé de licence et de conformité d’exportation, et l’accord de licence de contributeur dont chaque ingénieur est couvert dès le premier jour. Les champions gèrent la revue locale et entraînent leurs équipes sur la contribution. La banque finance plusieurs fondations dont les projets sous-tendent ses systèmes de trading, contribue des correctifs en amont à un cadriciel de données largement utilisé pour cesser de maintenir une bifurcation, et exécute l’InnerSource à travers deux cents dépôts internes pour que toute équipe puisse envoyer une demande de tirage à toute autre. Le temps jusqu’à l’approbation pour une contribution standard est sous deux jours, suivi comme métrique que l’OSPO rapporte trimestriellement.

Gouvernement. Une agence numérique nationale opère sous un mandat « code source ouvert par défaut » et argent-public-code-public. Son OSPO publie les nouveaux services dans un dépôt public sauf si une exemption documentée s’applique pour la sécurité ou la vie privée, exploite un catalogue intergouvernemental pour que les agences réutilisent le code avant de le construire, et écrit des exigences de code source ouvert et de normes ouvertes dans les marchés publics pour que les fournisseurs livrent du code réutilisable et bien documenté avec le gouvernement gardant les droits. Le bureau gère aussi la divulgation de sécurité coordonnée pour le code qu’il publie et finance la maintenance d’une bibliothèque d’identité partagée dont plusieurs agences dépendent maintenant, pour qu’aucune équipe unique ne possède silencieusement un composant dont tout le gouvernement dépend.

Argumentaire économique : motivations, retour sur investissement et coût total de possession

Le retour le plus clair est l’élimination de surprises évitables et coûteuses. Le code source ouvert non géré produit des crises qui arrivent selon leur propre calendrier : une violation de copyleft qui fait surface pendant la diligence raisonnable d’acquisition, une migration d’urgence hors d’un composant mort, une brèche tracée à une dépendance qu’aucun inventaire ne listait. Un OSPO convertit ces événements à faible probabilité et coût élevé en travail stable et budgété. Superposez les économies récurrentes de remonter en amont : chaque correctif privé que vous retirez cesse de taxer chaque mise à niveau future, et à travers un grand parc, cela se compose en vraie capacité d’ingénierie retournée au travail produit.

Sur le registre du coût total de possession, le bureau est bon marché relatif à ce qu’il protège. Son coût est une petite équipe, un certain outillage de scan et de catalogue, et un financement de mainteneur modeste. Mettez cela contre le coût de ne pas l’avoir : responsabilité légale, diligence raisonnable échouée ou retardée, incidents de sécurité, constructions internes dupliquées de choses qui existent déjà comme code source ouvert, et le saignement lent de bifurcations que personne n’a choisi de garder. Il y a aussi des retours à la hausse plus difficiles à tarifer mais réels : influence sur la direction des composants dont vous dépendez, un avantage de recrutement et de réputation d’une présence de code source ouvert crédible, et une livraison plus rapide parce que les ingénieurs réutilisent au lieu de reconstruire. Quand vous faites valoir le dossier auprès de la direction, cadrez l’OSPO comme de la gestion de chaîne d’approvisionnement pour la majorité de votre base de code, avec un dividende stratégique par-dessus. Dans le gouvernement, ajoutez la dimension de conformité, puisque l’ouverture est souvent mandatée et bien la faire évite à la fois la non-conformité et la dépense publique dupliquée.

Anti-patterns et pièges

L’OSPO comme porte. Un bureau qui révise et bloque seulement, n’habilite jamais, est contourné, produisant les dépendances fantômes qu’il était censé prévenir.
Le théâtre de contribution. Annoncer une stratégie de code source ouvert tout en rendant le processus d’approbation si lent que personne ne contribue réellement.
La publication abandonnée. Publier un projet avec un article de blog de lancement, puis ne jamais trier un problème, nuisant à votre réputation plus que le silence ne le ferait.
Bifurquer-et-oublier. Bifurquer une dépendance pour un correctif puis la porter pour toujours, dérivant loin des correctifs de sécurité en amont.
Profiter des mainteneurs fragiles. Dépendre d’une bibliothèque critique à mainteneur unique et ne jamais financer, remercier, ou aider la personne derrière.
La négligence de marque. Publier un projet sans protéger son nom, puis regarder une bifurcation ou un fournisseur profiter de votre réputation.
La propriété seulement juridique. Loger l’OSPO entièrement dans le juridique pour que ses conseils ne portent aucune crédibilité d’ingénierie et que les équipes les ignorent.
Les métriques de vanité. Compter les étoiles et mentions de presse au lieu de la santé de dépendance, le temps jusqu’à l’approbation, et les correctifs privés retirés.

Modèle de maturité

Niveau 1, Initier : Les ingénieurs ajoutent, corrigent, et publient occasionnellement du code source ouvert sans politique et sans propriétaire. La consommation, contribution, et publication sont réactives et ad hoc, pilotées par l’initiative individuelle. Les bifurcations privées s’accumulent inaperçues, personne ne finance aucun projet en amont, et personne ne pourrait répondre à une question de licence pendant la diligence raisonnable.
Niveau 2, Développer : Des pratiques de base apparaissent mais varient par équipe. Une politique de consommation approximative et une liste de licences approuvées existent, et quelqu’un est vaguement responsable, pourtant la contribution est lente et cas par cas et certains groupes en font bien plus que d’autres. Quelques dépendances critiques sont connues, mais la durabilité, les publications, et la gestion restent incohérentes.
Niveau 3, Standardiser : Un OSPO chartré possède la consommation, la contribution, la publication, et la communauté, et les pratiques sont documentées et appliquées à travers l’organisation. Le scan et une nomenclature logicielle sont automatisés, un accord de contributeur préclarifié et un chemin d’approbation rapide existent, les projets publiés portent une vraie gouvernance, des marques, et des politiques de sécurité, et l’InnerSource se répand. Les équipes gouvernementales publient par défaut.
Niveau 4, Gérer : La fonction de code source ouvert est mesurée et contrôlée contre des référentiels. Le temps jusqu’à l’approbation est suivi contre une cible, le volume de contribution et le taux d’acceptation en amont sont rapportés, des tableaux de bord de santé de dépendance et de compte de mainteneur signalent les points uniques de défaillance, la couverture de mainteneur financé des dépendances à plus haut risque est surveillée, et l’inventaire de correctifs privés et bifurcations tend à la baisse trimestre après trimestre. Les projets publiés ont des temps de réponse de problème mesurés, les exceptions sont révisées selon une cadence, et les métriques de vanité comme les étoiles sont abandonnées en faveur de celles-ci.
Niveau 5, Orchestrer : Le code source ouvert est une capacité stratégique gérée, intégrée avec la planification d’ingénierie, juridique, de sécurité, et de marchés publics et adaptée continuellement. La contribution est routinière, les mainteneurs et fondations critiques sont financés, l’organisation gère des projets bien exploités et dirige les écosystèmes dont elle dépend, et l’InnerSource est la norme. Les métriques d’engagement et de santé alimentent l’amélioration continue, et le portefeuille est rééquilibré à mesure que les dépendances, risques, et mandats changent.

Pistes de réflexion

Où est la ligne entre un OSPO qui habilite et un qui conditionne, et comment sauriez-vous de l’extérieur lequel vous avez construit ?
Lesquels de vos correctifs ou bifurcations privés portez-vous par habitude plutôt que nécessité, et que faudrait-il pour remonter les trois principaux en amont ?
Comment devriez-vous décider quels mainteneurs et fondations financer quand la liste de dépendances critiques est plus longue que le budget ?
Qu’est-ce qui changerait véritablement dans votre prochaine publication si vous deviez la publier avec une vraie gouvernance, une marque, et une politique de divulgation coordonnée dès le premier jour ?
Pour les lecteurs du secteur public, quel est un processus défendable pour exempter du code de la publication par défaut sans éroder silencieusement le principe ?
Quelles bibliothèques internes bénéficieraient le plus de l’InnerSource, et qu’est-ce qui empêche une autre équipe de vous envoyer une demande de tirage aujourd’hui ?

Points clés à retenir

Un OSPO possède toute la relation avec le code source ouvert : consommer de façon responsable, contribuer en amont, publier vos propres projets, et soutenir les mainteneurs dont vous dépendez.
Contribuer en amont est de la stratégie, pas de la charité ; cela supprime la taxe récurrente des correctifs privés, achète de l’influence sur la direction, et aide au recrutement.
Faites du chemin conforme le chemin le plus rapide à travers l’automatisation et la curation, pour que le bureau habilite les ingénieurs au lieu de les conditionner.
Publiez vos propres projets seulement avec une vraie gouvernance, une licence choisie, une marque protégée, et une divulgation de sécurité coordonnée, ou ne les publiez pas du tout.
Financez et aidez les mainteneurs critiques sur lesquels votre système de production repose, parce que le commun n’est pas autoportant.
Appliquez l’InnerSource pour apporter la collaboration de code source ouvert à l’intérieur de l’entreprise, et dans le gouvernement, préférez par défaut l’ouvert, publiez par défaut, et réutilisez avant de construire.

Références et lectures complémentaires

Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software
Nadia Eghbal, Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure
Karl Fogel, Producing Open Source Software: How to Run a Successful Free Software Project
Danese Cooper et Klaas-Jan Stol (éditeurs), Adopting InnerSource: Principles and Case Studies
The Linux Foundation et TODO Group, OSPO guides and Open Source Program Office resources
The Linux Foundation et TODO Group, State of OSPOs and Open Source Management (série d’enquêtes annuelles)
Heather Meeker, Open (Source) for Business
Open Source Initiative, The Open Source Definition et liste de licences approuvées
Free Software Foundation Europe, matériaux de campagne Public Money, Public Code
U.S. Federal Source Code Policy et orientation Code.gov