10.18 Escritório de programa de código aberto (OSPO) e contribuição upstream

Visão geral e motivação

A sua organização já roda sobre software de código aberto: os sistemas operacionais, as linguagens, os bancos de dados e as bibliotecas que carregam o seu produto são em grande parte escritos por pessoas que não trabalham para vocês. O capítulo 10.3 cobre a contratação e a conformidade de licenças, e o capítulo 10.12 cobre a decisão entre aberto e fechado. Este capítulo trata da função que dá coerência a tudo isso: um escritório de programa de código aberto (OSPO), a equipe que responde por como a empresa consome, contribui e lança código aberto. Um OSPO é o centro de gravidade de uma relação que de outro modo está espalhada por todo engenheiro que digita import.

A maioria das organizações entra no código aberto de costas, uma dependência por vez, e depois descobre a exposição acumulada de uma só vez: uma pergunta de licença durante a diligência de uma aquisição, uma biblioteca crítica com um mantenedor exausto, um alerta de segurança em código que ninguém sabia estar entregando. Um OSPO transforma essa correria numa capacidade gerida. Define uma política de consumo que habilita em vez de bloquear, decide quando contribuir upstream serve ao negócio, cuida dos projetos que vocês lançam e aplica a colaboração aberta dentro da empresa por meio do InnerSource. É uma função estratégica, ligada aos valores da sua engenharia de software (capítulo 1.1), não uma caixinha de conformidade.

Para as empresas o motor é a escala: milhares de dependências, obrigações de exportação e de licença em várias jurisdições e centenas de engenheiros que tomam, cada um, pequenas decisões de código aberto todos os dias. Um único escritório dá espinha a essa dispersão. Para o governo o motor é a política e a confiança pública. “Código aberto por padrão” e “dinheiro público, código público” são cada vez mais lei, então os órgãos públicos precisam de alguém que consiga publicar código com segurança, reutilizar entre agências e cobrar dos fornecedores o cumprimento de padrões abertos. Nos dois contextos o OSPO se paga convertendo risco invisível e sem preço em trabalho deliberado e orçado.

Princípios fundamentais

O código aberto é uma relação de mão dupla, não um armazém gratuito. Vocês consomem, contribuem e lançam, e um OSPO responde pelos três.
Contribuir é estratégia, não caridade. Fazer upstream reduz o custo de carregar patches privados e compra influência.
Habilitem o caminho rápido, não guardem o portão. Uma política mais lenta que copiar código será ignorada, então façam do caminho em conformidade o mais veloz.
Financiem os mantenedores de quem vocês dependem. O bem comum não se sustenta sozinho, e a sua biblioteca mais crítica pode ter um único autor não remunerado.
Cuidem do que lançam, ou não lancem. Um projeto abandonado prejudica mais a sua reputação do que nenhum projeto jamais prejudicaria.
Meçam o engajamento para poder melhorá-lo. Contem contribuições, saúde das dependências e tempo até a aprovação, não comunicados de imprensa.
No governo, o padrão é aberto e publicar por padrão. A abertura é a norma; o fechamento é a exceção documentada.

Recomendações

Monte um OSPO do tamanho da sua realidade

Vocês não precisam de uma equipe grande para começar. Numa startup um OSPO pode ser um engenheiro com um mandato escrito e algumas horas por semana. Numa empresa é um pequeno grupo central mais uma rede federada de campeões embutidos nas equipes de produto. Seja qual for o tamanho, deem-lhe uma carta clara cobrindo quatro responsabilidades: política de consumo e conformidade, contribuição upstream, lançamento e cuidado dos próprios projetos e relações de comunidade e de financiamento. Coloquem-no onde enxergue a engenharia e o jurídico, muitas vezes reportando ao CTO ou a um VP de engenharia com linha pontilhada para o jurídico e a segurança. O modo de falha é um OSPO que vive inteiramente dentro do jurídico e vira freio; o conserto é dotá-lo de engenheiros que entregam, para que a orientação dele tenha credibilidade nas equipes que atende.

Consuma com responsabilidade e faça do caminho seguro o caminho fácil

O consumo é por onde entra a maior parte do risco, então tornem o bom comportamento sem esforço. Ofereçam um catálogo interno curado de componentes pré-avaliados, varredura automatizada de licenças e vulnerabilidades no pipeline e padrões claros que um desenvolvedor possa seguir sem abrir um chamado. Apoiem-se na disciplina de licenças do capítulo 10.3 e nas práticas de cadeia de suprimentos e saúde das dependências do capítulo 2.18: fixem versões, gerem uma lista de materiais de software, vigiem a cadeia de suprimentos de software atrás de pacotes comprometidos ou abandonados e acompanhem o fim de vida antes que ele force uma migração. O trabalho do OSPO não é aprovar à mão cada dependência. É construir os guardrails para que noventa e cinco por cento das escolhas sejam seguras automaticamente e só os casos genuinamente incomuns cheguem a um humano.

Contribua upstream porque compensa, não porque é bonito

Tratem a contribuição upstream como uma decisão econômica. Todo patch privado que vocês carregam contra uma dependência é um imposto pago a cada atualização, para sempre, até a mudança entrar upstream ou o fork se afastar tanto que vocês passem a ser donos dele por inteiro. Contribuir a correção de volta apaga esse imposto. O upstream também compra influência sobre a direção, de modo que o roteiro de um componente de que vocês dependem se curva às suas necessidades, e sinaliza competência aos engenheiros que vocês querem contratar. Deem aos desenvolvedores um caminho rápido e documentado: um contrato de licença de contribuidor ou certificado de origem do desenvolvedor pré-aprovado, uma aprovação leve que confirme que a mudança é segura de compartilhar e tempo de gestão orçado para o trabalho. Quando a alternativa é manter um fork permanente de um projeto que vocês não controlam, contribuir de volta é quase sempre mais barato.

Lance os seus próprios projetos com governança real

Quando vocês abrirem o código de um software que construíram, façam-no deliberadamente ou não façam. Decidam primeiro se o código é uma commodity que vale compartilhar ou um diferencial que vale manter fechado, usando o raciocínio do capítulo 10.12. Se lançarem, escolham uma licença que combine com a sua intenção (permissiva para maximizar a adoção, copyleft para manter o ecossistema recíproco), documentem quem decide o quê por meio de um modelo de governança escrito e registrem a marca do nome do projeto para poder protegê-lo do mau uso mantendo o código livre. Comprometam-se com o cuidado real: um rastreador de problemas público, um guia de contribuição, um código de conduta e uma política de segurança com divulgação coordenada para que quem reporta saiba como alcançá-los (capítulo 4.2). Nomeiem um mantenedor e orcem o tempo dele. Um projeto lançado com alarde e abandonado em um ano faz mais dano à sua reputação do que um que nunca foi entregue.

Aplique o InnerSource para colaborar dentro da empresa

Os hábitos que fazem o código aberto funcionar (repositórios públicos, guias claros de contribuição, revisão por mérito, baixas barreiras para um primeiro patch) funcionam igualmente bem atrás do firewall. InnerSource significa que qualquer engenheiro pode encontrar, usar e melhorar qualquer projeto interno, enviando um pull request através das fronteiras de equipe em vez de abrir um chamado e esperar. Isso derruba silos, espalha o reúso de código e treina as pessoas exatamente no fluxo que usarão ao contribuir externamente. O OSPO é o lar natural do InnerSource porque já é dono das ferramentas e do manual cultural. Comecem com algumas bibliotecas compartilhadas de alto valor, publiquem internamente seus guias de contribuição e recompensem as equipes que aceitam patches de fora com elegância.

Financie e sustente os mantenedores de quem vocês dependem

O seu sistema em produção pode repousar numa biblioteca mantida por uma pessoa no tempo livre. Isso é um risco de cadeia de suprimentos, e a resposta honesta é ajudar a carregar o peso. Identifiquem as dependências mais críticas na lista de materiais, achem as de base fina de mantenedores e escolham uma resposta para cada uma: patrocinar o mantenedor diretamente, contribuir tempo de engenharia, entrar numa fundação que financia o projeto ou, como último recurso, preparar-se para fazer fork ou substituir. Financiar o bem comum é mais barato que a emergência que se segue ao seu colapso, e mantém saudáveis, e movendo-se numa direção que vocês podem influenciar, os componentes em que se apoiam.

Defina uma política de contribuição que aprove rápido

Uma política de contribuição existe para dizer sim depressa, não para dizer não devagar. Especifiquem o que um engenheiro pode contribuir sem perguntar (correções de bugs, documentação, pequenas funcionalidades em projetos que vocês já usam), o que precisa de uma verificação leve (qualquer coisa que toque um diferencial ou uma patente) e como a propriedade intelectual e os acordos de contribuidor são tratados uma vez, centralmente, em vez de por contribuição. Automatizem as partes chatas: verificações de licença, um acordo corporativo de contribuidor pré-assinado e um bot que sinalize o raro envio que precisa de olhos humanos. Meçam o tempo até a aprovação e tratem uma fila lenta como um bug na política.

Compromissos: prós e contras

Abordagem	Prós	Contras
OSPO central	Política consistente, perícia profunda, responsabilidade clara	Pode virar gargalo se só barra e nunca habilita
OSPO federado (campeões nas equipes)	Escala, mantém as decisões perto dos engenheiros	Exige forte coordenação ou a política se dispersa
Contribuir upstream	Apaga o imposto do patch privado, compra influência, ajuda a recrutar	Esforço contínuo, revisão de PI, trabalho no cronograma de outrem
Carregar forks privados	Controle total, entrega no seu prazo	Imposto permanente de manutenção, afasta-se das correções de segurança upstream
Lançar o seu próprio projeto	Ecossistema, reputação, manutenção compartilhada	Custo real de cuidado. O abandono prejudica a reputação
Financiar mantenedores	Protege dependências críticas, compra boa vontade	Custo direto, e escolher quem financiar é político
Nenhum OSPO (ad hoc)	Custo zero de montagem	Dívida jurídica, de segurança e de sustentabilidade invisível

A tensão central é entre controle e habilitação. Um OSPO que revisa à mão cada dependência e cada contribuição parece seguro, mas vira aquilo que os engenheiros contornam, o que produz as dependências-sombra invisíveis que vocês queriam evitar. Um OSPO que só publica orientação animada sem qualquer imposição automatizada é ignorado no instante em que um prazo se aproxima. A resolução é a mesma que percorre o capítulo 10.3: automatizem o caso comum para que o caminho em conformidade seja o mais rápido e reservem o julgamento humano para o genuinamente novo. Acertem esse equilíbrio e o escritório é um multiplicador de força; errem em qualquer direção e ele é um freio ou uma decoração.

Perguntas para discutir com sua equipe

Quem é dono da sua relação com o código aberto hoje, e essa pessoa conseguiria responder amanhã a uma pergunta difícil? Se os advogados de um possível comprador pedissem o seu inventário de licenças, ou um repórter perguntasse que biblioteca sem manutenção fica no seu caminho de pagamentos, há um nome ligado à resposta? Para a maioria das organizações a resposta honesta é “ninguém”, o que significa que cada engenheiro está fazendo política em silêncio e ninguém responde pela soma. Levem a evidência à reunião: tentem produzir a lista de licenças aprovadas, a lista de materiais de software e a pessoa que atenderia a uma pergunta de copyleft durante uma diligência. Se esses artefatos não existem ou apontam para ninguém, vocês acharam a sua primeira tarefa de OSPO. A decisão a tomar não é se ter a função, e sim quem é dono dela e que mandato carrega, mesmo que o escritório seja uma pessoa um dia por semana.
Vocês carregam patches privados que poderiam enviar upstream, e quanto isso está custando? Muitas equipes mantêm uma pilha discreta de modificações locais contra suas dependências, reaplicando-as à mão a cada atualização e absorvendo a dor do merge como se fosse uma lei da natureza. Cada um desses patches é um imposto recorrente, e cada um é candidato a ser contribuído de volta para que o imposto desapareça. Levem os detalhes: listem os forks e patches locais que o seu build de fato carrega, estimem as horas de engenharia que cada um custa por ano e anotem quais projetos upstream provavelmente aceitariam a mudança. A consideração contrária é real, já que o upstream exige esforço agora e corre no cronograma do mantenedor, mas a comparação é com pagar o imposto do patch para sempre. A resposta deve transformar “a gente sempre só reaplica” numa escolha deliberada, com um caminho de contribuição rápido o bastante para os engenheiros o usarem.
Que dependência doeria mais se o mantenedor fosse embora, e o que vocês farão a respeito? Em algum lugar da sua pilha há um componente que pararia um serviço crítico para a receita ou a missão se quebrasse, mantido por uma pessoa ou um punhado de pessoas que vocês nunca financiaram nem agradeceram. O bem comum parece gratuito até o momento em que deixa de ser, e a versão cara dessa lição é a correria após um abandono ou uma vulnerabilidade sem correção. Levem a lista de materiais e classifiquem as dependências por raio de impacto, depois anotem o número de mantenedores e a situação de financiamento das primeiras. Para cada uma crítica e de pouca gente, decidam de antemão se vocês patrocinarão, contribuirão tempo, entrarão numa fundação ou se prepararão para substituir. Isso converte um ponto único de falha latente numa relação gerida, mantida ao mesmo padrão de qualquer outro risco operacional (capítulo 2.18).
Antes de abrir o código da próxima ferramenta interna, vocês estão prontos para cuidar dela por anos, ou estão entregando um lançamento e um pedido de desculpas futuro? Um lançamento público é um compromisso permanente: um rastreador de problemas que alguém precisa triar, uma caixa de segurança que alguém precisa vigiar e um nome que alguém precisa defender. As equipes recorrem ao código aberto para ajudar no recrutamento ou na boa vontade e depois descobrem que um projeto abandonado com problemas parados prejudica a reputação que esperavam construir, mais do que não ter entregado nada. Levem a evidência: listem os projetos que vocês já lançaram e, para cada um, mostrem a idade dos problemas abertos, se um mantenedor nomeado tem horas orçadas, se há um modelo de governança, uma marca registrada e uma política de divulgação coordenada, e se o código é uma commodity que vale compartilhar ou um diferencial que vocês deveriam manter fechado (capítulo 10.12). A consideração contrária é que o cuidado real custa tempo de engenharia que vocês poderiam gastar no produto, então a escolha honesta muitas vezes é lançar menos coisas e cuidar bem delas. Para uma empresa isso significa revisão jurídica e de marca antes do lançamento; para o governo, que a marca, o canal de divulgação e o processo de exceção à publicação por padrão estejam resolvidos antes de o repositório ficar público.
Quanto tempo leva de fato para um engenheiro ter uma dependência aprovada ou uma contribuição liberada, e isso é mais lento que contornar vocês? Uma política de código aberto compete diretamente com o atalho mais rápido que um engenheiro consegue achar, e qualquer processo mais lento que copiar o código é contornado, produzindo as dependências-sombra invisíveis que o escritório devia prevenir. A tensão é controle contra habilitação: toda revisão manual acrescenta um rastro de auditoria e pega o raro problema genuíno, mas também acrescenta latência que empurra o caso mediano para fora do caminho em conformidade. Levem os números à reunião: o tempo medido até a aprovação de uma dependência padrão e de uma contribuição padrão, a parcela das decisões tratada automaticamente versus por um humano e a contagem de exceções que de fato precisaram de julgamento no último trimestre. Numa empresa com centenas de engenheiros tomando pequenas decisões diariamente, uma fila de dois dias vira em silêncio milhares de revisões contornadas; no governo, a mesma latência colide com obrigações de contratação e auditoria que exigem o rastro documental que o atalho pula, de modo que o conserto é automatizar o caso comum e não dotar de pessoal um portão maior.
Quais projetos internos mais se beneficiariam do InnerSource, e o que impede hoje outra equipe de enviar um pull request a vocês? As práticas que fazem o código aberto funcionar (repositórios públicos, guias de contribuição, revisão por mérito, uma baixa barreira para o primeiro patch) rendem atrás do firewall ao derrubar silos, espalhar o reúso e treinar as pessoas exatamente no fluxo que usarão para contribuir externamente. A consideração contrária é que abrir um projeto interno exige um guia de contribuição, capacidade de revisão sobrando e uma decisão sobre qual código deve permanecer restrito por razões de segurança ou regulatórias. Levem os detalhes: nomeiem as bibliotecas compartilhadas de alto valor, anotem quais já publicam um guia interno de contribuição e descrevam como um pull request entre equipes é tratado hoje, se é bem-vindo ou se perde numa fila. Para uma empresa o ganho se mede em construções internas duplicadas evitadas entre muitas equipes; para o governo, o mesmo hábito se estende pelas fronteiras das agências como reúso entre agências, de modo que a publicação por padrão e os componentes compartilhados reduzem o gasto público duplicado em vez de multiplicá-lo.

Perspectiva por setor

Startup. Deem o escritório a um engenheiro nomeado por algumas horas por semana com uma carta de uma página, não a um comitê. Adotem como padrão licenças permissivas com um scanner no pipeline, façam upstream só dos poucos patches privados que doem de fato a cada atualização e montem um pequeno patrocínio mensal para a biblioteca de mantenedor solitário sem a qual vocês genuinamente não vivem. A velocidade importa mais que a cobertura aqui: um caminho em conformidade mais rápido que copiar código vence uma política minuciosa que ninguém segue.

Pequena empresa. Vocês não terão um OSPO dedicado, então comprem a capacidade embutida nas ferramentas que já rodam: um scanner que sinalize problemas de licença e de vulnerabilidade e um catálogo curado de componentes pré-avaliados. Enquadrem o trabalho como higiene de conformidade de licenças e de saúde das dependências e não como um programa: saibam o que há na sua lista de materiais de software, saibam a que cada licença obriga e saibam qual dependência de mantenedor único doeria se desaparecesse. Prefiram comprar varredura e catalogação a construir as suas próprias.

Grande empresa. Rodem um pequeno escritório central mais uma rede federada de campeões embutidos nas equipes de produto, para que a política permaneça consistente enquanto as decisões ficam perto dos engenheiros. Automatizem a varredura de licenças, vulnerabilidades e exportação, cubram todo engenheiro com um acordo de contribuidor pré-aprovado e acompanhem o tempo até a aprovação como métrica reportada. Financiem as fundações por trás das suas dependências críticas, rodem InnerSource em muitos repositórios e gerenciem todo o patrimônio como um portfólio com métricas de saúde e engajamento e não como um amontoado de decisões individuais.

Governo. Operem sob código aberto por padrão e dinheiro público, código público: publiquem novos serviços em um repositório público a menos que se aplique uma exceção documentada de segurança ou privacidade. Mantenham um catálogo entre agências para que as equipes reutilizem antes de construir, escrevam requisitos de código aberto e de padrões abertos na contratação para que os fornecedores entreguem código reutilizável com os direitos retidos e cuidem da divulgação coordenada do que publicam. Financiem a manutenção das bibliotecas compartilhadas de que várias agências dependem, para que nenhuma equipe isolada seja dona em silêncio de uma infraestrutura em que todo o governo se apoia.

Exemplos

Startup. Uma startup de vinte pessoas faz da sua engenheira de plataforma sênior a dona de meio período do OSPO, com uma carta de uma página. Ela define uma política simples de consumo (licenças permissivas pré-aprovadas, copyleft revisado, scanner no pipeline) e nota que a equipe carrega três patches privados contra uma biblioteca de filas de código aberto, reaplicados dolorosamente a cada atualização. Ela faz upstream dos três; dois são aceitos em um mês, apagando de vez o imposto da atualização. Ela abre o código de uma pequena ferramenta interna com um README de verdade, uma licença e um contato de segurança, principalmente para atrair engenheiros, e monta um patrocínio mensal para o parser de mantenedor solitário de que o produto depende. Nada disso exige novas vagas, só um dono nomeado e um mandato claro.

Grande empresa. Um banco global mantém um OSPO central de seis pessoas mais uma rede federada de campeões de código aberto embutidos em cada grupo de produto. A equipe central é dona da política, da varredura automatizada de licenças e de conformidade de exportação e do contrato de licença de contribuidor que cobre todo engenheiro desde o primeiro dia. Os campeões cuidam da revisão local e orientam suas equipes na contribuição. O banco financia várias fundações cujos projetos sustentam seus sistemas de negociação, contribui correções upstream para um framework de dados muito usado para deixar de manter um fork e roda InnerSource em duzentos repositórios internos para que qualquer equipe possa enviar um pull request a qualquer outra. O tempo até a aprovação de uma contribuição padrão é inferior a dois dias, acompanhado como métrica que o OSPO reporta trimestralmente.

Governo. Uma agência digital nacional opera sob um mandato de “código aberto por padrão” e de dinheiro público, código público. Seu OSPO publica novos serviços em um repositório público a menos que se aplique uma exceção documentada por segurança ou privacidade, mantém um catálogo de todo o governo para que as agências reutilizem o código antes de construí-lo e escreve requisitos de código aberto e de padrões abertos na contratação para que os fornecedores entreguem código reutilizável e bem documentado, com o governo mantendo os direitos. O escritório também cuida da divulgação coordenada de segurança do código que publica e financia a manutenção de uma biblioteca de identidade compartilhada de que várias agências agora dependem, de modo que nenhuma equipe isolada seja dona em silêncio de um componente em que todo o governo se apoia.

Justificativa de negócio: motivações, ROI e TCO

O retorno mais claro é a eliminação de surpresas evitáveis e caras. O código aberto não gerido produz crises que chegam no seu próprio cronograma: uma violação de copyleft descoberta na diligência de uma aquisição, uma migração de emergência para fora de um componente morto, uma violação rastreada até uma dependência que nenhum inventário listava. Um OSPO converte esses eventos de baixa probabilidade e alto custo em trabalho regular e orçado. Somem a isso a economia recorrente do upstream: cada patch privado que vocês aposentam deixa de taxar toda atualização futura, e num grande patrimônio isso se compõe em capacidade real de engenharia devolvida ao trabalho de produto.

No livro-razão do custo total de propriedade, o escritório é barato em relação ao que protege. Seu custo é uma pequena equipe, algumas ferramentas de varredura e catálogo e um modesto financiamento de mantenedores. Contraponham ao custo de não tê-lo: responsabilidade jurídica, diligência falha ou atrasada, incidentes de segurança, construções internas duplicadas de coisas que já existem como código aberto e a lenta sangria de forks que ninguém escolheu manter. Há também retornos positivos mais difíceis de precificar mas reais: influência sobre a direção dos componentes de que vocês dependem, uma vantagem de recrutamento e reputação vinda de uma presença crível em código aberto e entrega mais rápida porque os engenheiros reutilizam em vez de reconstruir. Ao defender o caso junto à liderança, enquadrem o OSPO como gestão da cadeia de suprimentos da maior parte da sua base de código, com um dividendo estratégico por cima. No governo, acrescentem a dimensão de conformidade, já que a abertura costuma ser obrigatória e fazê-la bem evita tanto a não conformidade quanto o gasto público duplicado.

Antipadrões e armadilhas

O OSPO como portão. Um escritório que só revisa e bloqueia, nunca habilita, é contornado, produzindo as dependências-sombra que devia prevenir.
Teatro de contribuição. Anunciar uma estratégia de código aberto enquanto se torna o processo de aprovação tão lento que ninguém de fato contribui.
O lançamento abandonado. Publicar um projeto com um post de blog de lançamento e nunca triar um problema, prejudicando a reputação mais que o silêncio.
Fork e esquecer. Fazer fork de uma dependência por uma correção e depois carregá-lo para sempre, afastando-se dos patches de segurança upstream.
Carona em mantenedores frágeis. Depender de uma biblioteca crítica de mantenedor único e nunca financiar, agradecer ou ajudar a pessoa por trás dela.
Negligência de marca. Lançar um projeto sem proteger o nome e depois ver um fork ou fornecedor negociar com a sua reputação.
Posse só do jurídico. Alojar o OSPO inteiramente no jurídico, de modo que sua orientação não tem credibilidade de engenharia e as equipes a ignoram.
Métricas de vaidade. Contar estrelas e menções na imprensa em vez de saúde das dependências, tempo até a aprovação e patches privados aposentados.

Modelo de maturidade

Nível 1, Iniciar: Os engenheiros adicionam, corrigem e ocasionalmente publicam código aberto sem política e sem dono. Consumo, contribuição e lançamento são reativos e ad hoc, movidos pela iniciativa individual. Os forks privados se acumulam sem ser notados, ninguém financia qualquer projeto upstream e ninguém conseguiria responder a uma pergunta de licença durante uma diligência.
Nível 2, Desenvolver: Aparecem práticas básicas, mas variam por equipe. Existem uma política de consumo rudimentar e uma lista de licenças aprovadas, e alguém é vagamente responsável, mas a contribuição é lenta e caso a caso e alguns grupos fazem muito mais que outros. Algumas dependências críticas são conhecidas, mas sustentabilidade, lançamentos e cuidado permanecem inconsistentes.
Nível 3, Padronizar: Um OSPO com carta é dono de consumo, contribuição, lançamento e comunidade, e as práticas são documentadas e impostas em toda a organização. A varredura e a lista de materiais de software são automatizadas, existem um acordo de contribuidor pré-aprovado e um caminho rápido de aprovação, os projetos lançados têm governança real, marcas e políticas de segurança e o InnerSource está se espalhando. As equipes de governo publicam por padrão.
Nível 4, Gerenciar: A função de código aberto é medida e controlada em relação a linhas de base. O tempo até a aprovação é acompanhado contra uma meta, o volume de contribuições e a taxa de aceitação upstream são reportados, painéis de saúde das dependências e de contagem de mantenedores sinalizam pontos únicos de falha, a cobertura de mantenedores financiados das dependências de maior risco é monitorada e o inventário de patches e forks privados tende a cair trimestre a trimestre. Os projetos lançados têm tempos de resposta a problemas medidos, as exceções são revisadas numa cadência e métricas de vaidade como estrelas são abandonadas em favor dessas.
Nível 5, Orquestrar: O código aberto é uma capacidade estratégica gerida, integrada ao planejamento de engenharia, jurídico, segurança e contratação e adaptada continuamente. A contribuição é rotineira, mantenedores críticos e fundações são financiados, a organização cuida de projetos bem conduzidos e orienta os ecossistemas de que depende, e o InnerSource é a norma. As métricas de engajamento e de saúde alimentam a melhoria contínua, e o portfólio é reequilibrado conforme dependências, riscos e mandatos mudam.

Ideias para discussão

Onde fica a linha entre um OSPO que habilita e um que barra, e como vocês saberiam, de fora, qual construíram?
Quais dos seus patches ou forks privados vocês carregam por hábito e não por necessidade, e o que seria preciso para fazer upstream dos três principais?
Como decidir quais mantenedores e fundações financiar quando a lista de dependências críticas é maior que o orçamento?
O que mudaria de verdade no seu próximo lançamento se vocês tivessem de publicá-lo com governança real, uma marca e uma política de divulgação coordenada desde o primeiro dia?
Para os leitores do setor público, qual é um processo defensável de isentar código da publicação por padrão sem erodir em silêncio o princípio?
Quais bibliotecas internas mais se beneficiariam do InnerSource, e o que impede hoje outra equipe de enviar um pull request a vocês?

Principais conclusões

Um OSPO é dono de toda a relação com o código aberto: consumir com responsabilidade, contribuir upstream, lançar os próprios projetos e sustentar os mantenedores de quem vocês dependem.
Contribuir upstream é estratégia, não caridade; apaga o imposto recorrente dos patches privados, compra influência sobre a direção e ajuda a recrutar.
Façam do caminho em conformidade o caminho mais rápido por meio de automação e curadoria, para que o escritório habilite os engenheiros em vez de barrá-los.
Lancem os seus projetos apenas com governança real, uma licença escolhida, uma marca protegida e divulgação coordenada de segurança, ou não os lancem.
Financiem e ajudem os mantenedores críticos em que o seu sistema de produção repousa, porque o bem comum não se sustenta sozinho.
Apliquem o InnerSource para trazer a colaboração do código aberto para dentro da empresa e, no governo, adotem o aberto como padrão, publiquem por padrão e reutilizem antes de construir.

Referências e leitura complementar

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