Deseja tornar este livro melhor? Isso é incrível!

O livro Padrões InnerSource em si é um projeto de código aberto e acolhe qualquer forma de contribuição. Nada é insignificante!

Não importa se deseja nos auxiliar a corrigir erros de gramática/ortografia, melhorar o design ou contribuir com padrões inteiramente novos baseados nas experiências InnerSource que teve em seu local de trabalho. Amamos todas essas contribuições! :)

Se nunca contribuiu para um projeto de código aberto anteriormente, saiba que a comunidade Padrões InnerSource é formada por pessoas amigáveis e é um ambiente seguro para experimentar.

Antes de Começar

As fontes dos Padrões InnerSource e deste livro estão mantidas em um repositório no GitHub. Portanto, será necessário ter uma conta de usuário no GitHub para fazer edições e sugestões neste livro. Caso não possua uma ainda, visite github.com e crie uma conta gratuitamente.

Diferentes Formas de Contribuir

Aqui estão algumas maneiras pelas quais pode contribuir:

1. Corrigir erros de ortografia, formatação ou outras falhas que notar neste livro.

2. Melhorar o conteúdo de um padrão existente (por exemplo, adicionando uma breve descrição de como está usando um padrão como uma Instância Conhecida).

3. Contribuir com um novo padrão, descrevendo como superou desafios relacionados ao InnerSource em sua organização.

Para (1) e (2) acima, pode simplesmente clicar no link Editar no GitHub que vê no topo de cada página deste livro. Isso o levará diretamente ao arquivo correspondente em nosso repositório GitHub, onde pode sugerir suas alterações.

Para (3), será necessário clonar o repositório InnerSourcePatterns e adicionar um novo arquivo com o padrão que está sugerindo. Ao fazer contribuições maiores para este livro, revise nosso CONTRIBUTING.md e também nosso Manual do Colaborador.

Licença das Contribuições

O conteúdo deste repositório está licenciado sob CC-BY-SA-4.0. Ao contribuir para este repositório, nos concede (e a todos os outros, também) o direito de usar sua contribuição de acordo com essa licença.

Cada vez mais padrões estão sendo contribuídos para este livro pela comunidade InnerSource Commons. Isso é incrível!

Agora, como tornar mais fácil para os leitores descobrirem os padrões que podem ajudá-los em sua situação específica?

Para esse propósito, fornecemos este mapa mental. Ele classifica os padrões com base nas diferentes fases de um Programa InnerSource e nos desafios que podem surgir nas respectivas fases.

Melhore este Mapa Mental

Se você notar algo neste mapa mental que pareça errado, por favor abra uma issue, descrevendo o problema e a correção que deve ser feita.

Além disso, se você tiver outras ideias para melhorar a descoberta desses padrões ou quiser tornar este mapa mental melhor, revise a documentação de nossa abordagem de Categorização de Padrões e também veja como contribuir para este livro.

Referências

A ideia de categorizar os padrões dessa forma é vagamente baseada em uma descrição em Thoughts on an InnerSource Pattern Language por Tim Yao, Bob Hanmer e Padma Sudarsan (2018). Para detalhes específicos, veja o slide 15 na apresentação.

• Introdução

• Sumário

• Explorar Padrões

• Contribuir para Este Livro

Padrões

• Avaliação de Projeto entre Equipes - É difícil vender o valor de projetos InnerSource entre equipes que não proporcionam um impacto direto na receita da empresa. Aqui está uma maneira baseada em dados para representar seu projeto que articula seu valor e o amplifica.

• Casos de uso do Issue Tracker - A equipe responsável pelo InnerSource falha em tornar não apenas os planos e o progresso transparentes, mas também o contexto das mudanças. Isso é resolvido aumentando os casos de uso do Issue Tracker do projeto para também servir como espaço para brainstorming, discussões de implementação e design de recursos.

• Colaborador Contratado - Associados que desejam contribuir com o InnerSource são desencorajados a fazê-lo por sua gerência de linha. O alívio é fornecido por meio de contratos e acordos formais.

• Comitê de Revisão - O Modelo de Trabalho InnerSource é uma ruptura radical das abordagens mais tradicionais, tanto para desenvolvedores quanto para gerentes. Ao estabelecer um Comitê de Revisão como uma interface entre a iniciativa InnerSource e todos os gerentes sêniores das unidades de negócios que participam dela, é mais provável que estes últimos se familiarizem com a iniciativa e a apoiem, uma vez que isso lhes proporciona um certo nível de supervisão e controle sem promover a microgestão.

• Documentação Base Padrão - Novos contributors para um projeto InnerSource têm dificuldade em descobrir quem é o responsável pelo projeto, o que trabalhar e como contribuir. Fornecer documentação em arquivos padrão como README.md/CONTRIBUTING.md permite um processo de autoatendimento para novos contributors, para que possam encontrar as respostas para as perguntas mais comuns por conta própria.

• Documente seus Princípios Orientadores - A explicação comum do InnerSource, "aplicando as melhores práticas de código aberto dentro de uma organização", não funciona bem com pessoas que não possuem um background em código aberto. Como solução, os princípios mais importantes do InnerSource são documentados e publicados amplamente.

• Elogiar Participantes - Após uma contribuição de InnerSource, é importante agradecer ao contribuidor pelo seu tempo e esforço. Este padrão fornece orientações que não apenas reconhecem efetivamente a contribuição, mas também promovem um maior envolvimento do contribuidor e de outros.

• Equipe Central - Mesmo quando um projeto InnerSource é amplamente necessário, as contribuições e uso podem ser prejudicados porque o projeto é difícil de trabalhar. Estabelecer uma equipe central dedicada a cuidar dos itens fundamentais do projeto. O trabalho deles permite que os contributors adicionem e usem recursos que oferecem valor para seus cenários.

• Extensões para Crescimento Sustentável - Um projeto InnerSource está recebendo um grande número de contribuições, tornando a manutenção difícil. Ao oferecer um mecanismo de extensão fora do projeto principal, os mantenedores possibilitam a expansão das capacidades do projeto com custos mínimos e sobrecarga de manutenção.

• Ferramentas de Comunicação - Os usuários de um projeto InnerSource têm dificuldade em obter ajuda e entrar em contato com a equipe responsável pelo projeto. Ao usar consistentemente ferramentas de comunicação assíncronas, o projeto torna as discussões visíveis, arquivadas e pesquisáveis, o que leva a um nível melhorado de suporte para os usuários.

• Garantia de 30 dias - Ao aceitar contribuições de fora da sua própria equipe, há uma aversão natural em assumir a responsabilidade pelo código que não foi escrito pela própria equipe. Através da Garantia de 30 dias, a equipe contribuinte concorda em fornecer correções de bugs para a equipe receptora, o que aumentará o nível de confiança entre as duas equipes e torna mais provável que as contribuições sejam aceitas.

• Gig Marketplace - Estabeleça um mercado criando um site intranet que liste necessidades específicas de projetos InnerSource como "Gigs", com requisitos explícitos de tempo e habilidades. Isso permitirá que os gerentes entendam melhor o compromisso de tempo de seus funcionários e os benefícios profissionais, aumentando assim a probabilidade de obter a aprovação para fazer contribuições InnerSource.

• Inicie como um Experimento - Comece a sua iniciativa InnerSource como um experimento com limite de tempo para tornar mais fácil para os gestores que não estão familiarizados com o InnerSource endossar e apoiar a iniciativa.

• Licença InnerSource - Duas entidades jurídicas que pertencem à mesma organização desejam compartilhar código-fonte de software entre si, mas estão preocupadas com as implicações em termos de responsabilidades legais ou contabilidade entre empresas.

• Líder de Comunidade Dedicado - Selecione pessoas com habilidades tanto em comunicação quanto em técnicas para liderar as comunidades e garantir o sucesso na iniciativa InnerSource

• Modelo de Maturidade - As equipes começaram a adotar o InnerSource. A prática está se espalhando para vários departamentos. No entanto, a compreensão do que constitui um projeto InnerSource varia. A solução é fornecer um modelo de maturidade para permitir que as equipes realizem uma autoavaliação e descubram padrões e práticas das quais ainda não têm conhecimento.

• Portal InnerSource - Potenciais contribuidores não conseguem descobrir facilmente os projetos de InnerSource que lhes interessam. Ao criar um site de intranet que indexa todas as informações disponíveis sobre projetos de InnerSource, você permite que os contribuidores aprendam sobre projetos que possam interessá-los e que os proprietários de projetos de InnerSource atraiam um público externo.

• Processo de Liberação Padrão - As equipes podem hesitar em adotar um projeto InnerSource se não tiverem certeza de sua maturidade. Para abordar isso, notas de lançamento consistentes e artefatos publicados são cruciais. Essas práticas demonstram um compromisso sólido com o projeto, transmitindo confiança e garantindo aos usuários o comprometimento contínuo com software sustentável e bem gerenciado.

• Repositório Pontuação de Atividade - Potenciais contribuidores desejam encontrar projetos InnerSource ativos que precisem de sua ajuda. Ao calcular uma pontuação de atividade do repositório para cada projeto, uma lista classificada de projetos pode ser criada (por exemplo, no Portal InnerSource), para que os potenciais contribuidores possam determinar mais facilmente em qual projeto desejam contribuir.

• Requisitos Comuns - O código comum em um repositório compartilhado não está atendendo às necessidades de todas as equipes de projeto que desejam usá-lo; isso é resolvido por meio do alinhamento de requisitos e refatoração.

• Serviço vs. Biblioteca - Equipes em um ambiente DevOps podem relutar em trabalhar além dos limites de suas equipes em bases de código comuns, devido à ambiguidade sobre quem será responsável por responder a interrupções de serviço. A solução é perceber que muitas vezes é possível implantar o mesmo serviço em ambientes independentes com cadeias de escalonamento separadas no caso de interrupções de serviço, ou separar grande parte do código compartilhado em uma biblioteca única e colaborar nela.

• Suporte em Grupo - O que acontece se uma equipe ou indivíduo não suporta mais um projeto InnerSource? Mantenha o projeto vivo formando um grupo de indivíduos interessados.

• Tomada de Decisão Transparente entre Equipes usando RFCs - Projetos InnerSource que desejam alcançar altas taxas de participação e tomar as melhores decisões possíveis para todos os envolvidos precisam encontrar maneiras de criar sistemas participativos ao longo de todo o ciclo de vida do software. A publicação de documentos internos de "Requests for Comments" (RFCs) permite discussões desde o início do processo de design e aumenta as chances de construir soluções com um alto grau de comprometimento de todas as partes envolvidas.

• Trusted Committer - Muitos projetos InnerSource se encontram em uma situação em que consistentemente recebem feedback, funcionalidades e correções de bugs de contribuidores. Nessas situações, os mantenedores do projeto buscam maneiras de reconhecer e recompensar o trabalho do contribuidor acima e além de contribuições individuais.

Apêndice

• Modelo de Padrão

• Extras

  • Modelo de README

  • Modelo de CONTRIBUTING

Recursos

• Este livro no GitHub

• InnerSource Commons

Title

Colaborador Contratado

Patlet

Associados que desejam contribuir com o InnerSource são desencorajados a fazê-lo por sua gerência de linha. O alívio é fornecido por meio de contratos e acordos formais.

Problema

Sem o suporte da gerência intermediária, é provável que o número total de colaboradores e, consequentemente, a quantidade de contribuições feitas e o valor gerado pela iniciativa InnerSource fiquem abaixo das expectativas da gerência de nível superior. Isso provavelmente será amplificado se não houver financiamento adequado e capacitação dos Líderes Comunitários Dedicados. Isso corre o risco de fazer com que a gerência de nível superior abandone a ideia do InnerSource.

Contexto

Uma grande corporação iniciou uma iniciativa InnerSource. Os principais objetivos da iniciativa são aumentar a eficiência do desenvolvimento de software distribuído e promover a inovação, permitindo que todos os associados contribuam voluntariamente para projetos InnerSource, independentemente do tópico e unidade de negócios.

A gerência de nível superior está apoiando a iniciativa InnerSource. Para eles, a iniciativa InnerSource é apenas uma de muitas iniciativas para promover a inovação e a eficiência. Eles estão financiando o InnerSource com dinheiro e capacidade para líderes de comunidade e estão dando autonomia quanto à forma como o orçamento é gasto. Eles também estão limitando a amplitude e duração da iniciativa e participam de revisões periódicas até que haja comprovação de que ela produz os resultados esperados (consulte o Comitê de Revisão). A gerência de nível superior anunciou seu apoio ao InnerSource em várias reuniões internas da empresa.

No entanto, a gerência de nível superior ainda não capacitou ou incentivou os gerentes de nível intermediário a permitir ou até mesmo motivar seus funcionários a participar de atividades de InnerSource interdepartamentais. Além disso, a capacidade de cada associado geralmente é alocada para projetos não InnerSource por 100% do seu tempo de trabalho. A colaboração interorganizacional ainda não é a norma e os gerentes de linha geralmente não têm metas fora de sua própria organização. Espera-se que as contribuições para projetos InnerSource sejam feitas durante o horário de trabalho, e não durante o tempo livre.

Forças

• Os gerentes são responsáveis pelos resultados de suas unidades de negócio. Permitir que sua equipe participe de atividades de InnerSource que possam gastar tempo fazendo contribuições fora de sua unidade de negócio reduz efetivamente a capacidade de sua unidade. Isso provavelmente tornará mais difícil para os gerentes atingir ou exceder seus objetivos.

• Os gerentes de linha e os recursos humanos, por padrão, avaliarão o desempenho de seus subordinados em relação aos objetivos de suas unidades de negócio, o que pode não estar alinhado com os objetivos da comunidade InnerSource.

• Quanto menos cobertura executiva um gerente de linha perceber que tem, menos provável é que ele ou ela faça com que sua equipe participe de atividades de InnerSource que contribuam para outra unidade de negócio.

• Quanto menos transparência e controle um gerente de linha tiver sobre o trabalho realizado por um de seus subordinados, menos provável é que permita que ele contribua.

• Quanto menos formalmente o trabalho em InnerSource for gerenciado e organizado, menos provável é que um gerente de linha acostumado a processos formais aprove a contribuição de um de seus funcionários para o InnerSource.

• Quanto mais tempo um associado gasta em contribuições para um projeto InnerSource que não beneficia seu trabalho diário, mais aumentará a carga de trabalho para seus colegas de equipe em sua unidade de negócio.

• Os contribuidores individuais provavelmente considerarão a participação no InnerSource como uma oportunidade para melhorar sua rede profissional dentro da empresa e adquirir conhecimento e experiência na área técnica de suas contribuições.

Solução

Estabeleça um contrato formal entre o contribuidor, seu gerente de linha e um escritório de governança InnerSource (ISGO) financiado e dirigido centralmente. O ISGO reembolsará as unidades de negócios que contrataram os contribuidores pelo tempo contratado.

• O contrato especifica uma porcentagem máxima do tempo de trabalho do associado em InnerSource.

• O contrato declara claramente que o trabalho na unidade de negócios do contribuidor tem prioridade sobre o trabalho em InnerSource.

• O contrato afirma que não é necessário trabalhar em InnerSource pelo percentual máximo especificado no contrato.

• O contrato é assinado pelo contribuidor, pelo gerente de linha do contribuidor, pelo escritório de governança e pelo Dedicated Community Leader da comunidade na qual o contribuidor irá contribuir.

• O escritório de governança oferece mediação entre o contribuidor e seu gerente de linha em caso de conflito relacionado ao tempo para contribuições.

• O Dedicated Community Leader participa ou fornece informações para as avaliações de desempenho dos contribuidores contratados por mais de 20%.

Contexto Resultante

A formalização do contrato e o reembolso financiado centralmente comunicam de maneira convincente o apoio da organização à iniciativa InnerSource, o que capacita a gestão intermediária a aprová-la:

• A alocação de fundos corporativos às unidades de negócios para o reembolso da capacidade de desenvolvimento sinaliza aos gerentes de linha que InnerSource é considerado valioso pela organização, que tem cobertura executiva e que se espera que eles também o apoiem.

• Um contrato formal sinaliza que o trabalho em InnerSource é gerenciado profissionalmente e inspira confiança.

• Um contrato formal aumenta a transparência e fornece uma melhor visão geral sobre a capacidade disponível do associado para sua unidade de negócios e projetos InnerSource, reduzindo assim o risco de "capacidade superagendada/sobrecarregada".

Um contrato formal também é benéfico para os contribuidores e comunidades:

• Com um grupo estável de contribuidores, é mais provável que alguns deles eventualmente alcancem o status de Trusted Committer.

• Um contrato formal fornece uma base para resolver conflitos relacionados à participação em atividades InnerSource. Note que a mediação provavelmente terá sucesso apenas em algumas empresas com uma cultura propícia a isso.

Instâncias Conhecidas

• BIOS at Robert Bosch GmbH

Estado

• Structured

Autores

• Georg Grütter (Robert Bosch GmbH)

Reconhecimento

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Jim Jagielski

• Tim Yao

• Cedric Williams

• Klaas-Jan Stol

• Padma Sudarsan

• Nick Stahl

• Ofer Hermoni

• Robert C. Hanmer

Changelog

• 2016-10-25 - first review

• 2017-05-09 - rework

• 2017-09-08 - second review, final rework and merged

• 2021-02-27 - fixing issues with display of the pattern in the book

Histórico de Tradução

• 2023-04-20 - Tradução Eneri Junior

• 2023-04-20 - Tradução Humberto Zilio

Title

Casos de uso do Issue Tracker

Patlet

A equipe responsável pelo InnerSource falha em tornar não apenas os planos e o progresso transparentes, mas também o contexto das mudanças. Isso é resolvido aumentando os casos de uso do Issue Tracker do projeto para também servir como espaço para brainstorming, discussões de implementação e design de recursos.

Problema

Uma equipe desenvolve um componente no qual muitas equipes na organização dependem. Eles utilizam um Issue Tracker padrão para acompanhar bugs abertos e solicitações de recursos. No entanto, o contexto em cada entrada é muito limitado. Como resultado, possíveis colaboradores não têm como saber exatamente sobre qual alteração cada problema está tratando.

Contexto

A infraestrutura de ferramentas do projeto InnerSource está toda configurada. No entanto, o Issue Tracker do projeto é principalmente usado para compartilhar o progresso. Nos projetos InnerSource, existem muitos outros casos de uso em que um Issue Tracker pode ser usado para facilitar a comunicação remota e assíncrona.

Forças

• Os colaboradores gostariam de saber se a funcionalidade que estão procurando já está no roadmap. No entanto, devido à falta de contexto nas issues, é impossível determinar se as issues existentes atendem às necessidades da equipe de contribuição.

• Como resultado, muitas issues duplicadas estão sendo abertas, o que a equipe responsável precisa lidar.

• Como o contexto nas issues abertas é tão limitado, os colaboradores não conseguem ajudar a equipe responsável implementando issues mais simples que já estão abertas. Como resultado, grande parte do trabalho continua nas mãos da equipe responsável.

• Com um foco forte na comunicação verbal, é impossível discernir após alguns meses ou anos por que uma determinada funcionalidade foi escolhida para implementação. Como resultado, refatorações, em particular a simplificação do componente, se tornam um exercício de arqueologia de projetos e de solicitar informações de pessoas que se lembram do que foi discutido.

Solução

Abraçar a filosofia de "escrito em vez de verbal" não apenas para o desenvolvimento de software puro, mas também durante a fase de planejamento de novas funcionalidades:

• Para bugs, funcionalidades planejadas e ideias de funcionalidades, crie issues separadas. Em cada uma delas, inclua o máximo de informações possível para que potenciais colaboradores externos possam entender o contexto. Idealmente, especialmente para alterações mais simples, inclua informações suficientes para que colaboradores externos possam apoiar a equipe responsável implementando a funcionalidade em questão.

• Potencialmente, use o rastreador de problemas como um canal para fazer perguntas. Isso é especialmente útil se você não tiver outras fontes de comunicação para lidar com perguntas dos usuários.

• Faça uso de tags e categorias para distinguir issues usadas para diferentes propósitos.

• Para iniciar uma sessão de brainstorming de forma assíncrona, abra uma issue para coletar ideias. Quando a discussão começar a diminuir, resuma os pontos identificados nesta issue em um documento separado. Envie-o para revisão como uma solicitação de pull para aprofundar os pontos individuais que ainda precisam de esclarecimentos. O documento resultante pode ser usado para publicar os resultados em outros canais apropriados, bem como para referência futura.

• A maioria das implementações de rastreadores de problemas permite o uso de modelos de issues. Faça uso deles não apenas para coletar informações comumente necessárias para relatórios de bugs, mas também inclua dicas sobre que tipo de informações são necessárias para os outros tipos de uso.

Contexto Resultante

• Fazer um uso mais intenso do Issue Tracker do projeto para comunicação permite que colaboradores externos acompanhem e tomem melhores decisões sobre o que contribuir.

• Um foco na comunicação escrita estruturada permite que membros da equipe responsável participem remotamente.

• Comunicar consistentemente por escrito significa que a documentação passiva das decisões do projeto acumula-se como um subproduto, em vez de exigir atenção adicional.

• O uso consistente de canais de comunicação públicos atrai mais pessoas para acompanhar uma discussão. Isso significa que há mais pessoas qualificadas que podem responder perguntas, contribuir para issues abertas ou apontar falhas em funcionalidades planejadas que, de outra forma, seriam descobertas apenas muito tempo depois.

• Mover discussões para uma plataforma de discussão pública cria uma oportunidade para potenciais colaboradores futuros observarem, acompanharem, se familiarizarem e aprenderem sobre os caminhos do projeto muito antes de precisarem se envolver pela primeira vez.

Instâncias Conhecidas

• Europace AG - See blog post Issue Use Cases

Autores

Isabel Drost-Fromm

Estado

Structured

Histórico de Tradução

• 2023-06-13 - Tradução Eneri Junior

• 2023-06-13 - Tradução Humberto Zilio

Title

Comitê de Revisão

Patlet

O Modelo de Trabalho InnerSource é uma ruptura radical das abordagens mais tradicionais, tanto para desenvolvedores quanto para gerentes. Ao estabelecer um Comitê de Revisão como uma interface entre a iniciativa InnerSource e todos os gerentes sêniores das unidades de negócios que participam dela, é mais provável que estes últimos se familiarizem com a iniciativa e a apoiem, uma vez que isso lhes proporciona um certo nível de supervisão e controle sem promover a microgestão.

Problema

Os gerentes perceberão o Modelo de Trabalho InnerSource como uma ruptura radical dos modelos de trabalho aos quais estão acostumados e têm experiência. Como consequência, é provável que eles rejeitem ou façam uma microgestão da iniciativa InnerSource para tentar minimizar o risco percebido dessa mudança. Em ambos os casos, os benefícios do InnerSource não podem ser obtidos. Como resultado, o InnerSource é subsequentemente desacreditado.

Contexto

A Empresa A deseja introduzir sua primeira iniciativa InnerSource. A maioria dos gerentes na Empresa A não está familiarizada com o modelo de trabalho de Código Aberto e, em vez disso, está acostumada com um estilo de gestão hierárquico e de controle de cima para baixo.

Forças

• Quanto mais controle percebido um gerente tem sobre o trabalho na iniciativa InnerSource, mais provável é que ele ou ela apoie a iniciativa mesmo sem experiência prévia.

• Quanto menos experiência um gerente tem com o modelo de trabalho de Código Aberto, mais provável é que ele ou ela queira controlar o risco da iniciativa.

• Quanto mais rígidas e controladoras forem as iniciativas InnerSource gerenciadas, menos provável é que o modelo de trabalho de Código Aberto possa ser adotado na extensão necessária. Como resultado, os benefícios do InnerSource não serão obtidos.

Solução

• Estabelecer um comitê de revisão composto por gerentes seniores de todas as unidades de negócios que participam da iniciativa InnerSource.

• Os membros do comitê de revisão têm a autoridade para decidir em grupo quais projetos InnerSource receberão suporte de forma geral e financiamento em particular.

• Os candidatos podem ser eleitos pelos membros do comitê de revisão antes das reuniões para apresentar seus projetos InnerSource propostos durante as reuniões do comitê de revisão para consideração.

• Os líderes de projetos InnerSource atualmente financiados pelo comitê de revisão são obrigados a relatar o status de seus projetos durante todas as reuniões do comitê de revisão.

• Os membros do comitê de revisão são obrigados a fornecer feedback construtivo tanto para novos candidatos quanto para os líderes de projetos atuais durante as reuniões do comitê de revisão.

• Cada projeto InnerSource deve ter a chance de reagir ao feedback recebido em uma sessão do comitê de revisão até a próxima sessão, a fim de evitar o encerramento prematuro do projeto.

• Um líder de projeto InnerSource também pode apresentar a proposta de encerramento por conta própria em uma reunião do comitê de revisão. O comitê de revisão então deve decidir se as unidades de negócios que utilizam o software precisam ter tempo para implementar medidas para garantir que o desenvolvimento e/ou manutenção do código continue até que uma solução alternativa para o desenvolvimento pela comunidade InnerSource seja encontrada (se for relevante para o negócio ou crítico para a missão).

• O comitê de revisão deve se reunir regularmente. Uma frequência de duas reuniões por ano tem se mostrado bem-sucedida.

Contexto Resultante

• Os gerentes aplicam uma ferramenta com a qual estão familiarizados ao InnerSource para obter a quantidade necessária de informações e controle sobre o funcionamento interno da iniciativa InnerSource. Essa familiaridade tornará mais provável que eles aprovem a iniciativa InnerSource e concedam o grau necessário de liberdade para os projetos InnerSource.

• Os desenvolvedores ainda podem se auto-organizar até certo ponto. O microgerenciamento não ocorre porque o comitê de revisão se reúne com pouca frequência.

Instâncias Conhecidas

• BIOS at Robert Bosch GmbH

Estado

• Structured

• Finalized and Reviewed as of 8/31/17.

Autores

• Georg Grütter, Robert Bosch GmbH

• Diogo Fregonese, Robert Bosch GmbH

Alias

Cheese Interface

Histórico de Tradução

• 2023-08-20 - Tradução Eneri Junior

• 2023-08-20 - Tradução Humberto Zilio

Title

Documentação Base Padrão

Patlet

Novos contributors para um projeto InnerSource têm dificuldade em descobrir quem é o responsável pelo projeto, o que trabalhar e como contribuir. Fornecer documentação em arquivos padrão como README.md/CONTRIBUTING.md permite um processo de autoatendimento para novos contributors, para que possam encontrar as respostas para as perguntas mais comuns por conta própria.

Problema

Uma equipe deseja compartilhar um projeto recém-iniciado ou já existente com toda a organização e receber contribuições. Os potenciais contributors muitas vezes ficam perdidos: eles não conseguem identificar os canais de comunicação preferidos da equipe. Eles têm dificuldade em julgar rapidamente se uma nova funcionalidade faz sentido ser adicionada ou não. Eles têm dificuldade em entender exatamente quais colegas estão mantendo ativamente o projeto no momento.

Contexto

Um projeto será compartilhado com outros como um projeto InnerSource. Para que outros possam entender do que se trata o projeto e como contribuir, o projeto precisa fornecer alguma documentação básica. Até agora, o projeto não tem nenhuma documentação ou faltam alguns aspectos necessários para que os usuários possam testá-lo de forma autônoma e para que os contributors possam se atualizar rapidamente.

Forças

• O projeto foi convertido em um projeto InnerSource apenas recentemente. Antes, os usuários eram apenas internos ou passavam por sessões pessoais presenciais para serem integrados. Da mesma forma, as pessoas que trabalhavam no projeto passavam por sessões pessoais de integração que não escalavam com o aumento do número de contribuidores ou contribuidores remotos. Como resultado, falta documentação de autoatendimento.

• O projeto foi recém-criado como um projeto InnerSource. No entanto, a equipe anfitriã não tem experiência com InnerSource. Como resultado, eles precisam de orientação sobre quais informações incluir em sua documentação, onde colocar essa documentação para que outros possam encontrá-la e quais tipos de leitores abordar em sua documentação.

• O projeto foi convertido em um projeto InnerSource apenas recentemente e a equipe anfitriã tem pouca experiência com InnerSource. Como resultado, a documentação existente aborda muitos aspectos técnicos, mas não abrange a comunicação, coordenação e informações necessárias para facilitar o planejamento transparente.

• O projeto foi convertido em um projeto InnerSource apenas recentemente. Como resultado, muito conhecimento implícito que existe dentro da equipe não está escrito ou não é óbvio para os contributors.

• A falta de documentação faz com que potenciais contributors levem muito tempo para configurar e começar a trabalhar. Produzir documentação (e mantê-la atualizada) requer um investimento de tempo. Mesmo que a equipe anfitriã conte com contributors para ajudar com a documentação ausente, essas contribuições ainda precisam de tempo para serem revisadas.

• Os membros do projeto estão gastando muito tempo respondendo perguntas de como começar. Manter um banco de dados abrangente do que poderia ser considerado perguntas de suporte requer muito tempo e esforço.

• Diferentes equipes dentro da organização têm padrões divergentes para formatar o código-fonte e usar padrões de software. Como resultado, as contribuições muitas vezes acabam sendo reescritas em grande parte ou até mesmo completamente. Padronizar tudo isso e fazer cumprir o padrão muitas vezes exigiria muito tempo e trabalho.

• O trabalho adicional de explicações repetidas e reescritas diminui a utilidade da abordagem InnerSource.

• Escalações frequentes devido ao trabalho extra e atrasos devido a reescritas levam a uma situação de grande problema ("big cheese situation").

Solução

Abordar a necessidade de documentação mais clara para novos contribuidores. O objetivo ao criar essa documentação deve ser tornar o processo de início o mais automatizado possível, com perguntas frequentes respondidas em um formato padrão de documentação.

README.md

Se ainda não existir, crie um arquivo `README.md para o seu projeto. Ele deve conter:

• Missão do projeto de forma concisa possível. Deve responder qual é o propósito do projeto e permitir que os contributors façam uma boa primeira avaliação se um recurso sugerido provavelmente estará dentro do escopo do projeto ou não.

• Uma seção "Primeiros passos" para os usuários downstream do projeto. Deve explicar como configurar/integrar os artefatos do projeto, bem como uma explicação dos primeiros passos típicos para usuários iniciantes.

• Documentação mais detalhada para usuários do projeto - ou um link para isso.

• Documentação necessária para fazer modificações no projeto - ou um link para isso.

• Documentação sobre como contribuir para o projeto - ou um link para isso.

• Uma seção "Iniciando" que explique quais canais públicos, arquivados e vinculáveis de comunicação o projeto utiliza. Isso deve incluir um link para o rastreador de problemas do projeto, mas também para quaisquer outras mídias de discussão utilizadas.

• Uma seção "Quem somos" explicando quem são os Trusted Committers por trás do projeto - com uma explicação de que, em vez de entrar em contato com essas pessoas em particular, os canais públicos de comunicação acima devem ser usados para comunicação.

• Uma explicação dos critérios para o projeto transformar contributors em Trusted Committers - se esse caminho existir.

CONTRIBUTING.md

Se a explicação dos passos para fazer uma contribuição for muito complexa, crie um documento separado CONTRIBUTING.md. Este documento deve responder a perguntas frequentes que os contribuidores fizeram no passado. Não é necessário fornecer um livro abrangente de uma vez. Em vez disso, compartilhe informações que se mostraram necessárias para os contribuidores. Provavelmente, isso abordará um ou mais dos seguintes tópicos:

• Como fazer checkout do código fonte do projeto do controle de versão.

• Como fazer modificações no projeto (potencialmente incluindo informações sobre diretrizes de codificação).

• Como fazer build do projeto.

• Como executar testes para garantir que as modificações acima não estejam introduzindo novos bugs.

• Como enviar suas modificações de volta ao projeto.

• Algumas informações sobre o tempo de resposta esperado para as modificações feitas.

Existem muitos bons exemplos de como escrever um arquivo README.md e que tipo de informações incluir em um arquivo CONTRIBUTING.md em vários projetos de código aberto. Páginas como como escrever um readme que se destaca, o Guia de Código Aberto do GitHub e o livro Producing Open Source têm informações valiosas sobre que tipo de informações fornecer. Embora Producing Open Source não tenha um capítulo sobre como escrever um bom README em si, o capítulo Começando a partir do que você tem fornece uma lista bastante extensa de coisas que os membros da equipe, usuários e contributors precisarão. Os projetos InnerSource provavelmente não cobrirão todos esses aspectos desde o início, mas a própria lista é útil para inspiração do que pode ser abordado.

Além disso, este padrão vem com dois modelos básicos para você começar imediatamente: README-template.md e CONTRIBUTING-template.md

Contexto Resultante

• O tempo necessário para que os contribuidores se ambientem é significativamente reduzido.

• O tempo gasto respondendo às perguntas iniciais de Trusted Committers é significativamente reduzido, deixando-os mais tempo para trabalhar em outras tarefas.

• As escalonamentos devido a mal-entendidos e falta de alinhamento são significativamente reduzidos.

Instâncias Conhecidas

• Europace AG - Veja a postagem do blog InnerSource: Adicionando documentação básica

• Paypal Inc.

• Mercado Libre - criado um site de documentação que contendo informações sobre como começar com InnerSource e definido também os artefatos básicos que um repositório deve ter para ser InnerSource (README, CONTRIBUTING, CODING_GUIDELINES, etc.).

Autores

• Isabel Drost-Fromm

Alias

Fornecer documentação básica padrão através de um README

Estado

• Structured

• Drafted in December 2019.

Referências

• README-template.md and

• CONTRIBUTING-template.md

Créditos

Web and People illustrations by Storyset

Histórico de Tradução

• 2023-04-14 - Tradução Eneri Junior

• 2023-04-14 - Tradução Humberto Zilio

Title

Avaliação de Projeto entre Equipes

Patlet

É difícil vender o valor de projetos InnerSource entre equipes que não proporcionam um impacto direto na receita da empresa. Aqui está uma maneira baseada em dados para representar seu projeto que articula seu valor e o amplifica.

Contexto

• Você é responsável por uma equipe cross que serve como plataforma para outros na empresa.

• O projeto entre equipes não proporciona nenhum valor direto para a receita da empresa.

Problema

Projetos entre equipes podem ter um impacto muito grande na empresa, mas são difíceis de representar de maneira baseada em dados. Como resultado, é fácil e comum tanto buscar projetos que não fornecem valor real quanto subfinanciar o que, de outra forma, produziria grande valor.

Forças

• Os projetos precisam demonstrar valor (objetivo ou subjetivo) à liderança da empresa para serem financiados.

• O valor do projeto entre equipes é disperso em várias unidades de negócios finais.

• Devido a essa dispersão, o valor do projeto entre equipes é difícil de medir diretamente.

Solução

Estabeleça um padrão e modelo de como valorizar projetos entre equipes.

Tais modelos nos fornecem a ferramenta necessária para nos concentrarmos e ampliar a colaboração de alto valor para a empresa.

O core de todo o valor do projeto entre equipes é a ideia de que podemos realizar mais juntos do que separados. Atribuir valor a um esforço entre equipes é um exercício em quantificar quanto mais está sendo feito juntos. O delta exato na produtividade variará de acordo com o domínio e o projeto. Existe um processo comum pelo qual você pode criar um modelo para calculá-lo.

Explicação

Monte uma pequena equipe de especialistas em seu domínio. Usando essa equipe de especialistas, estime 4 coisas sobre cada consumidor de sua saída de projeto:

• Quanto tempo leva para que eles consumam a saída do seu projeto?

• Quanto tempo levaria para que eles criassem o valor da saída do seu projeto para si mesmos?

• Qual a porcentagem da saída do seu projeto é realmente útil para eles?

• Quanto tempo eles gastariam em manutenção da solução criada por eles mesmos, em base contínua (idealmente por uso)?

Ao fazer essas estimativas, é impossível saber com alta precisão exatamente quanto tempo cada atividade leva. Isso não é o seu objetivo. Em vez de exatidão, você deve se esforçar para estabelecer um limite mínimo nessas estimativas. A ideia é que o grupo de especialistas seja capaz de dizer uns aos outros: "Não sabemos exatamente quanto tempo levaria, mas todos concordamos que é pelo menos isso." Especificamente, você deve estimar um tempo máximo razoável para consumir a saída do seu projeto e tempos mínimos razoáveis para os consumidores, caso contrário, criar, usar e manter suas próprias soluções.

Uma observação sobre o custo de "criar sua própria solução" (home-roll). O custo de criar uma solução por conta própria NÃO é necessariamente o mesmo (muito improvável, na verdade) do custo de criar uma solução compartilhada. Muitas vezes, para a mesma funcionalidade, a modularidade e qualidade envolvidas na construção de uma solução compartilhada entre equipes tornam o investimento significativamente maior do que uma implementação rápida e codificada usada apenas uma vez.

Fórmula

Depois de estimar os limites piores casos, você pode calcular o valor da saída do seu projeto de equipe cross durante um determinado período de tempo usando a fórmula simples:

[Tempo Economizado] - [Tempo Investido]

([Número de novas implementações] * [Custo para desenvolver internamente] * [Porcentagem de funcionalidade útil] + [Número de usos] * [Custo de manutenção por uso]) - ([Número de novas implementações] * [Custo de implementação])

[Número de novas implementações] * ([Custo para desenvolver internamente] * [Porcentagem de funcionalidade útil] - [Custo de implementação]) + [Número de usos] * [Custo de manutenção por uso]

Comentário

Apesar das aparências de rigor, esse processo não produz uma forma exata de medir a saída de projetos entre equipes. Na prática, entretanto, ele oferece um modelo através do qual você pode tomar uma decisão adequada de como financiar esse trabalho. Depois de ter dados bons e razoáveis conforme explicado acima, você deve financiar horas de desenvolvimento dedicadas para executar o projeto em, pelo menos um dos três níveis abaixo:

1. O número de horas poupadas pela fórmula acima. Como todos temos certeza de que a fórmula produzirá um número abaixo do verdadeiro número de horas salvas, você pode ter a confiança de que financiar o projeto até esse ponto é uma vitória certa para você.

2. A quantidade de tempo que leva para dar suporte a contribuições internas para projetos entre equipes. Como o colaborador provavelmente teria feito o trabalho de qualquer maneira de forma única, vale a pena financiar o tempo que leva para facilitar o trabalho dele ser compartilhado.

3. Qualquer quantia que pareça boa para você. Um efeito colateral intencional de ter uma fórmula de valoração é que ela naturalmente força a medição dos pontos-chave de uso que fornecem valor aos consumidores.

Essas medidas podem ser compreendidas e utilizadas em sua forma bruta para lhe fornecer uma ideia intuitiva de quão valioso é o projeto.

Algumas pessoas podem se preocupar com a falta de precisão nessa abordagem de valoração. Mas tudo bem se esse processo não fornecer uma medição exata. Ele só precisa ser preciso o suficiente para cumprir dois objetivos:

1. Dar um meio de representar o valor do que está acontecendo para aqueles que estão organizando e financiando esforços entre equipes.

2. Ajudar aqueles envolvidos a saber quais áreas de esforço entre equipes são prioritárias com base em seu valor.

Na prática, desde que essas valorações estejam dentro de uma ordem de grandeza da realidade e uma da outra, elas são suficientemente precisas para cumprir esses propósitos. Elas fornecerão uma melhoria significativa nos resultados em relação às valorações ad hoc (e aos efeitos resultantes) descritas na seção Problema no início deste documento.

Contexto Resultante

• Meios baseados em dados para discutir o valor e financiamento do projeto de equipe cross com a liderança.

• Métricas-chave em torno do projeto de equipe cross instrumentalizadas em forma bruta.

• Definir como o projeto de equipe cross fornece valor tende a levar a ele produzir maior valor para a empresa.

• Projeto geralmente bem-sucedido e "buzz" em torno dele.

Instâncias Conhecidas

• Nike

Estado

• Structured

• Proven in multiple domains.

Autores

• Russ Rutledge

Reconhecimento

• Jeremiah Wright por me ensinar a pensar em projetos entre equipes como um negócio interno que opera na moeda do tempo dos desenvolvedores.

Histórico de Tradução

• 2023-04-27 - Tradução Eneri Junior

• 2023-04-27 - Tradução Humberto Zilio

Title

Elogiar Participantes

Patlet

Após uma contribuição de InnerSource, é importante agradecer ao contribuidor pelo seu tempo e esforço. Este padrão fornece orientações que não apenas reconhecem efetivamente a contribuição, mas também promovem um maior envolvimento do contribuidor e de outros.

Problema

Como podemos expressar adequadamente nossa gratidão a um contribuidor por sua contribuição para um projeto InnerSource? Pode ser fácil esquecer de fazer isso ou não saber as palavras ou o meio a usar para um efeito adequado e sincero. Elogios e agradecimentos são maneiras fáceis e acessíveis de manter os contribuidores e seus gerentes motivados e entusiasmados para continuar. Um padrão nesta área facilita a realização desse gesto e garante que a mensagem seja transmitida de forma clara e sincera.

Contexto

• Você é o Trusted Committer ou mantenedor de um projeto InnerSource.

• Você valoriza a comunidade de contribuidores e deseja mantê-la e fazê-la crescer.

Forças

• Você está ocupado, o que torna fácil esquecer de gestos suaves como elogios e agradecimentos.

• Você pode não ser alguém que se sinta confortável em situações sociais ou tenha facilidade com as palavras.

• O reconhecimento dos colegas é muito importante para a satisfação no trabalho e o desenvolvimento da carreira.

Solução

É gratificante para qualquer pessoa ser reconhecida por outros. Em um ambiente profissional, um aumento no reconhecimento também é uma via para um aumento de influência e crescimento. Toda vez que alguém contribuir para o seu projeto InnerSource, reconheça-os com um sincero e qualificado "obrigado".

Para contribuições não triviais (todas as contribuições de código e contribuições significativas de tempo), agradeça através dos seguintes mecanismos:

• Parece bom para qualquer pessoa ser reconhecida por outros. Em um ambiente profissional, um aumento no reconhecimento também é uma via para um aumento de influência e crescimento. Qualquer vez que alguém contribuir para o seu projeto InnerSource, reconheça-os com um sincero e qualificado "obrigado".

Para contribuições não triviais (todas as contribuições de código e contribuições significativas de tempo), agradeça através dos seguintes mecanismos:

(1) Chame a pessoa pelo nome em qualquer local de chat (por exemplo, Slack) onde você organize a atividade do projeto. Avise a todos o que eles fizeram e agradeça publicamente.

Exemplo:

Pessoal @aqui deem um high-five para @andrew.clegg por atualizar o rcs-viewer para a versão mais recente do hebo-client (https://github.com/rcs/rcs-viewer/pull/81). Obrigado por ajudar a manter esta biblioteca atualizada, Andy!

(2) Envie um e-mail para eles e seu gerente (em cópia) agradecendo-os pela contribuição. Para contribuições de código, muitas vezes você pode apenas encaminhar o e-mail de notificação de mesclagem.

Exemplo:

Olá, Andy, quero agradecer novamente por fazer esta atualização. Pode ter sido um pequeno período de tempo, mas é atenção como essa de cada pessoa que faz o projeto RCS funcionar para todos nós. Obrigado por resolver seu próprio problema de uma maneira que também melhora o rcs-viewer para todos.

Contexto Resultante

O feedback como esse deixa o contribuidor com um sentimento fantástico e pronto para voltar para mais. Combinar ambas as formas de agradecimento dá a eles reconhecimento diante de seus colegas (abrangência) e diante de seu gerente direto (profundidade). Há um incentivo sutil para que esses colegas no chat considerem contribuir também e para que o gerente busque circunstâncias apropriadas para incentivar seus outros subordinados a fazer o mesmo. Além disso, a conscientização sobre o projeto InnerSource se espalha para o gerente, que pode não ter conhecido previamente o uso e o envolvimento da equipe com ele.

Uma ressalva - seja autêntico. Certifique-se de que suas palavras derivem do sincero agradecimento que você sente por dentro pelo que eles fizeram. Mantenha o nível e a verbosidade dos elogios adequados ao nível de envolvimento deles. Exagerar pode parecer insincero e mecânico, derrotando o propósito de se comunicar.

Patterns Relacionados

• Apenas Diga Obrigado (do livro Fearless Change)

Instâncias Conhecidas

• Nike (multiple projects)

Estado

• Structured

Autores

• Russ Rutledge

Reconhecimento

• Todd Lisonbee por encorajar a "manter isto real"

• Isabel Drost-Fromm para esta explicação adicional de um agradecimento "qualificado".

Histórico de Tradução

• 2023-08-20 - Tradução Eneri Junior

• 2023-08-20 - Tradução Humberto Zilio

Title

Documente seus Princípios Orientadores

Patlet

A explicação comum do InnerSource, "aplicando as melhores práticas de código aberto dentro de uma organização", não funciona bem com pessoas que não possuem um background em código aberto. Como solução, os princípios mais importantes do InnerSource são documentados e publicados amplamente.

Problema

A organização está tentando implementar o InnerSource em uma escala maior. A iniciativa começou entre entusiastas de código aberto. O objetivo agora é obter a adesão de pessoas que não possuem experiência em código aberto. Para esse público, o slogan típico de "aplicar as melhores práticas de código aberto" não é mais suficiente para transmitir a mensagem do que é o InnerSource, quais problemas ele resolve e quais ferramentas ele usa para solucionar esses problemas. Como resultado, a adoção do InnerSource na organização diminui. As equipes desenvolvem ideias divergentes sobre os objetivos do InnerSource e como implementá-lo da melhor maneira, o que leva a confusão quando os contribuidores começam a cruzar as fronteiras das equipes

História

Experimentos iniciais em uma organização mostraram que as melhores práticas de colaboração em código aberto podem ser benéficas. O próximo passo agora é levar a iniciativa para equipes e indivíduos que não possuem um amplo conhecimento em código aberto.

A meta agora é comunicar claramente os objetivos da iniciativa InnerSource, bem como um caminho claro para alcançar os mesmos.

Contexto

• A terminologia InnerSource está circulando entre os funcionários.

• A iniciativa começou entre entusiastas do código aberto.

Forças

• As equipes têm dificuldade em comunicar exatamente quais são os aspectos importantes do InnerSource.

• As pessoas que não possuem experiência em código aberto falham em entender o que significa trazer as melhores práticas do código aberto para dentro da organização.

• No dia a dia, as equipes que tentam seguir as melhores práticas do InnerSource têm dificuldade em decidir se o que estão fazendo está alinhado com os valores gerais do InnerSource.

Solução

Aqueles que lideram a iniciativa InnerSource na organização precisam ajudar as equipes e indivíduos que têm pouco conhecimento em código aberto e, portanto, têm menos compreensão intuitiva do InnerSource.

A clareza deve ser fornecida às equipes e indivíduos por meio da documentação dessas duas áreas:

1. Propósito - Por que a organização deseja adotar o InnerSource?

2. Princípios - Quais são os princípios do InnerSource que ajudarão a enfrentar esses desafios?

As seguintes seções fornecem mais detalhes sobre ambos, destinados a servir como possíveis pontos de partida para documentá-los em sua organização.

Por que a organização quer adotar o InnerSource?

No passado, o InnerSource provou ser bem-sucedido em resolver várias questões comumente encontradas em organizações.

Porém, quais desafios organizacionais a sua organização espera melhorar usando o InnerSource?

Em vez de fazer generalizações, tente identificar exatamente as soluções que correspondam aos desafios da sua organização - de preferência com aqueles afetados pela mudança que você deseja ver.

Alguns desafios que outras organizações abordaram seguindo as melhores práticas do InnerSource:

• Reduzir silos de desenvolvimento causados por uma cultura excessiva de propriedade.

• Aumentar a velocidade de inovação, reduzindo o tempo gasto resolvendo problemas semelhantes, promovendo um código saudável para reutilização.

• Aumentar a velocidade de desenvolvimento através de uma melhor colaboração entre equipes.

• Resolver dependências de projetos/equipes além de "esperar" ou "construir soluções alternativas", reduzindo gargalos de engenharia.

• Aumentar a qualidade.

• Aumentar a satisfação dos funcionários.

• Aumentar o sucesso de novas contratações.

• Construir documentação acionável.

Quais princípios do InnerSource ajudarão a abordar esses desafios?

Uma vez que as equipes compreendem quais problemas o InnerSource irá ajudá-las a resolver, o próximo passo é explicar quais princípios ajudam a enfrentar esses desafios.

Com base nos princípios básicos de desenvolvimento de código aberto, as seguintes diretrizes têm se mostrado bem-sucedidas:

(1) O código deve ser hospedado de forma transparente dentro da organização.

O código-fonte, documentação e dados relevantes para o desenvolvimento do projeto devem estar disponíveis e serem facilmente encontrados por qualquer pessoa na organização.

(2) Contribuições em vez de pedidos de funcionalidade.

Todos os envolvidos em um projeto agem como potenciais colaboradores e são tratados e apoiados como tal. As contribuições permanecem como sugestões em vez de requisitos. A coordenação antes de uma contribuição ajuda a evitar esforço desperdiçado. Os projetos fornecem diretrizes de contribuição para evitar fricção.

(3) Erros são oportunidades de aprendizado.

Com o trabalho visível em toda a organização, qualquer erro é visível para todos. Como resultado, deve ser estabelecida uma cultura em que os erros sejam oportunidades de aprendizado em vez de falhas que devem ser evitadas a todo custo.

(4) Escrita acima de comunicação verbal.

Para projetos que envolvem várias equipes, potencialmente em horários de reunião divergentes, é necessário colaborar de forma assíncrona. O objetivo dos projetos InnerSource é recrutar novos colaboradores. Para isso, futuros colaboradores potenciais precisam ser capazes de acompanhar o progresso do projeto de forma autônoma com uma barreira muito baixa para entrada. Se a comunicação relevante do projeto acontecer por meio de comunicação síncrona, os argumentos discutidos precisam ser registrados no canal escrito - as decisões devem ser finalizadas apenas lá. Como efeito colateral, isso leva a uma documentação básica passiva que é muito valiosa para qualquer recém-chegado ao projeto.

(5) Permitir que conselhos escritos acumulem em um arquivo persistente e pesquisável.

Toda a comunicação do projeto, em particular as decisões tomadas e as discussões que levaram a essas decisões, precisam ser arquivadas. Deve ser possível referenciar a comunicação por meio de URLs estáveis. A comunicação anterior precisa ser armazenada de forma que possa ser facilmente pesquisada.

Dois avisos, no entanto:

1. Isso não substitui a documentação estruturada. No entanto, pode servir como ponto de partida para coletar documentação estruturada.

2. Há exceções à regra de que tudo deve ser escrito e acessível a toda a organização: discussões relacionadas a pessoas e discussões relacionadas à segurança são sensíveis e não devem ser realizadas publicamente.

(6) Recompensar Trusted Committership

Todas as contribuições (por exemplo, código fonte, documentação, relatórios de bugs, participação em discussões, suporte ao usuário, marketing) são bem-vindas e são recompensadas. Aqueles que demonstram apoio ao projeto são convidados como Trusted Committers. Todos os Trusted Committers de um projeto são publicados.

Contexto Resultante

• Membros da organização entendem quais desafios podem ser enfrentados aplicando as melhores práticas de InnerSource.

• Membros da organização sem experiência prévia em código aberto entendem os valores e princípios básicos dos projetos InnerSource.

• Membros da organização sem experiência prévia em código aberto conseguem verificar suas atividades diárias em relação a um conjunto de valores comuns estabelecidos.

• As práticas de desenvolvimento da organização se tornam mais semelhantes aos projetos de código aberto, tornando mais fácil para os membros da organização participar de projetos de código aberto.

Instâncias Conhecidas

Europace AG

Os princípios de InnerSource listados na Solução acima são em sua maioria baseados na experiência da Europace. Para mais detalhes, consulte Europace InnerSource Prinzipien (em alemão).

GitHub

Objetivo

Muitas vezes, na GitHub, trabalhamos em um modelo em que equipes contribuem com recursos para áreas fora de sua responsabilidade. Exemplos comuns incluem engenharia de vendas contribuindo com recursos para desbloquear uma venda, projetos especiais contribuindo com recursos urgentemente necessários e de alto impacto em todo o produto e uma equipe trabalhando em várias áreas para entregar uma funcionalidade.

Princípios

No geral, os princípios descritos neste documento visam evitar o aumento da dívida técnica e da carga de suporte para a equipe responsável. Muitas vezes, ajuda é oferecida a uma equipe porque eles estão atrasados devido aos custos de suporte e manutenção em sua área de responsabilidade e não têm capacidade para contribuir para o recurso. Qualquer novo recurso realizado por outra equipe que aumente essa carga de suporte ou dívida técnica significa ainda menos tempo para a equipe responsável trabalhar em novos recursos, portanto, queremos garantir que sejam feitos corretamente.

Ao mesmo tempo, buscamos ser uma empresa na qual os engenheiros trabalhem livremente em diferentes áreas e prioridades de negócios frequentemente exigem que contribuamos para áreas fora de nossas áreas principais de responsabilidade.

Um bom resumo dos princípios é deixar a área em tão bom estado quanto ou em melhor estado do que você a encontrou.

Com isso em mente, aqui estão os princípios em que concordamos:

• Evite produtos minimamente viáveis ​​(MVPs) que acumulam dívida de recursos. Está tudo bem lançar um MVP para obter feedback do cliente, mas a equipe que contribui deve estar comprometida em concluir o conjunto de recursos. Exemplos incluem:

  • Compromisso em ir além do MVP para uma solução que irá satisfazer a maioria dos clientes.

  • Suporte completo para administração de novos recursos (por exemplo, suporte na interface do usuário de configurações, em vez de apenas executar uma linha de comando).

  • Disponibilização de recursos tanto na interface do usuário quanto na API, em vez de fornecer apenas uma API (ou vice-versa).

  • Garantir que os recursos funcionem em ambientes de servidor local e em nuvem.

• Apoiar o trabalho de criação de novas funcionalidades desde o início até depois da sua implementação em produção

  • Coordenar o lançamento incremental

  • Lidar com os tickets de suporte

  • Planejar tempo para lidar com o feedback dos clientes (funcionalidades e bugs)

• Construir recursos da maneira correta (não acumular dívidas técnicas)

  • Concordar com requisitos e solução com as equipes de Produto e Engenharia

  • Arquitetura e design adequados

  • Certificar-se de que os dados sejam armazenados adequadamente para evitar migrações de dados posteriormente.

  • Telemetria adequada está em vigor

  • Cobertura de testes adequada está em vigor

  • Suportado em ambientes de produção na nuvem e local (incluindo configuração, backup/restauração, migrações, etc.)

  • Correção de bugs

  • Documentação atualizada

Compromisso

Usamos um modelo de engajamento porque gostamos de definir quais medidas concretas podem ser tomadas por uma equipe ao contribuir com recursos para áreas fora de sua área de responsabilidade.

Um modelo de envolvimento típico no GitHub é parecido com este:

• Obter a aprovação do conjunto de recursos e do plano de implementação do proprietário do produto.

• Obtenha a aprovação do projeto de engenharia, incluindo a abordagem dos requisitos não funcionais (telemetria, cobertura de testes, testes em vários ambientes e suporte) do proprietário da engenharia (geralmente o gerente e o diretor de engenharia).

• Faça revisões de código ao longo do processo, juntamente com a revisão de quaisquer requisitos novos ou alterados.

Robert Bosch GmbH

Objetivo

Promover a colaboração, o aprendizado e a inovação é o foco principal da iniciativa Bosch InnerSource (BIOS).

Princípios

Para isso, a Bosch aplicou os seguintes princípios:

• Abertura: Reduzimos as barreiras de entrada nas comunidades de BIOS o máximo que podemos.

• Transparência**: Somos radicalmente transparentes e compartilhamos nossos produtos de trabalho, nossa comunicação e nossa tomada de decisões com todos os associados da empresa.

• Voluntariedade**: A decisão de participar e contribuir com a comunidade da BIOS fica a cargo de cada associado. Os funcionários devem trabalhar na BIOS porque estão intrinsecamente motivados, e não porque o gerente lhes disse isso.

• Autodeterminação**: As comunidades da BIOS são livres para escolher no que trabalhar, quando trabalhar e quais ferramentas e processos usar para trabalhar.

• Meritocracia**: O poder é investido nos membros do projeto BIOS com base em seus méritos, ou seja, com base na qualidade e na quantidade de suas contribuições.

Os princípios Abertura, Transparência e Voluntariedade ajudaram a desenvolver diversas comunidades de associados intrinsecamente motivados. A Meritocracia provou ser uma motivação eficaz para fazer grandes contribuições. A Autodeterminação permitiu que as comunidades usassem seu tempo limitado para contribuições da maneira mais eficaz e eficiente.

Estado

Structured

Autores

• Isabel Drost-Fromm

• Georg Grütter

Reconhecimento

• Zack Koppert - for sharing GitHub's approach in the Known Instances

Alias

Explicit InnerSource Principles

Histórico de Tradução

• 2023-04-29 - Tradução Eneri Junior

• 2023-04-29 - Tradução Humberto Zilio

Title

Extensões para Crescimento Sustentável

Patlet

Um projeto InnerSource está recebendo um grande número de contribuições, tornando a manutenção difícil. Ao oferecer um mecanismo de extensão fora do projeto principal, os mantenedores possibilitam a expansão das capacidades do projeto com custos mínimos e sobrecarga de manutenção.

Problema

À medida que o número de contribuições para um repositório InnerSource maduro aumenta rapidamente, isso gera mais carga nas revisões de código e na manutenção. Isso resulta em um grande acúmulo de revisões de código ou na rejeição prematura de novas contribuições de recursos.

Como a equipe anfitriã pode permitir um lançamento mais rápido de novos recursos, incentivando a inovação e a experimentação, ao mesmo tempo em que mantém o repositório bem mantido?

História

Há um projeto estratégico que tem como objetivo coletar as melhores inovações dentro de um espaço de domínio em uma pilha comum, permitindo a reutilização de uma infraestrutura comum e proporcionando uma experiência do usuário padronizada. Através do InnerSource, várias equipes na organização que trabalham dentro do espaço de domínio têm a oportunidade de colaborar e contribuir com suas inovações para o código base comum.

No entanto, um grande número de contribuições em paralelo de vários desenvolvedores está tornando a manutenção do código base difícil. Isso está adicionando uma grande carga para os mantenedores do projeto, que assumem a responsabilidade pelas normas de qualidade do código e capacitam a comunidade através de várias formas de comunicação.

Os mantenedores do projeto estão em risco de esgotamento devido a:

• Um backlog interminável de solicitações de pull de colaboradores que precisam ser revisadas.

• Insatisfação no trabalho: A maioria do tempo dos mantenedores é gasta no suporte à comunidade, o que não deixa espaço para inovação.

• Percepção de falta de realização: Nem todos os recursos contribuídos têm demanda de usuários adequada e resultam em adoção subsequente.

• Liberações demoradas: Mais recursos no código base resultam em testes de longa duração.

• Aumento das atividades de manutenção: Mais bugs são relatados à medida que novas capacidades são adicionadas.

Muito tempo é gasto amadurecendo cada nova contribuição de recurso, antes mesmo que os potenciais usuários tenham a oportunidade de explorar o recurso para seus casos de uso. Se acontecer que o novo recurso não atende ao caso de uso, então todo o tempo gasto para atingir os padrões desejados de qualidade do código é desperdiçado.

Contexto

• Um código-fonte InnerSource estratégico está crescendo rapidamente com novas contribuições de recursos de vários funcionários.

• A proporção de revisores para contribuições resulta em um crescente backlog de solicitações de pull. Isso está atrasando o lançamento de novos recursos para a comunidade.

• A qualidade do código está degradando e a experiência do usuário está sendo impactada negativamente.

• Os mantenedores do código estão sobrecarregados e não conseguem acompanhar o influxo de contribuições e o aumento do suporte à comunidade.

• Alguns dos recursos contribuídos não estão sendo adotados pelos usuários e podem até se tornar completamente inativos. No entanto, mesmo que não sejam usados, esses recursos ainda adicionam à sobrecarga de manutenção.

• A organização está investindo pesadamente na consolidação das novas contribuições de recursos para manter os padrões de qualidade antes que as ideias sejam exploradas pela comunidade.

• O padrão se aplica a ambos os cenários:

  • Os mantenedores se veem rejeitando novas ideias de recursos para limitar o escopo do projeto. Isso está prejudicando a inovação na comunidade e restringindo ainda mais a expansão.

  • Para reduzir o backlog, novos recursos estão sendo lançados sem documentação completa, consolidação ou teste detalhado, o que cria uma experiência de usuário ruim. Isso também aumenta o tamanho do código, adicionando um grande grafo de dependências e tornando a manutenção difícil.

Forças

• Os mantenedores e proprietários do produto desejam permitir a expansão, incentivar a inovação e a experimentação sem serem excessivamente restritivos em relação às contribuições, ao mesmo tempo em que mantêm boas práticas de código e padrões de qualidade para a experiência do usuário.

• Uma grande quantidade de tempo é dedicada à consolidação e testes rigorosos de recursos para atender aos padrões do produto, mas os proprietários do produto podem querer permitir o lançamento mais rápido de novas inovações para que os produtos em adoção as explorem antes de investir tempo na consolidação das capacidades.

• Os mantenedores desejam incentivar a comunidade a compartilhar inovações que combinem as capacidades do produto com outros casos de uso, sem adicionar mais dependências ao repositório principal.

Solução

Permitir extensões/plugins em código-fonte InnerSource em grande escala pode aliviar a carga de manutenção dos mantenedores do repositório e permitir um lançamento mais rápido de novos recursos para que produtos em adoção possam explorar. Isso transfere a manutenção das capacidades para os proprietários de extensões e permite que o repositório principal suporte capacidades que foram adotadas de forma mais ampla e são mais estratégicas.

As extensões fornecem um filtro para novas capacidades que podem eventualmente ser movidas para o núcleo do projeto. As extensões também atuam como um ambiente de incubação e consolidação da comunidade, permitindo que grande parte da consolidação aconteça organicamente, em vez de em um processo de revisão custoso.

Para que o modelo de extensões seja bem-sucedido, há algumas considerações arquiteturais a serem mantidas em mente:

1. Fácil de criar: Para obter a participação da comunidade, as extensões precisam ser fáceis de criar.

   • Crie um modelo de repositório que as extensões devem usar como ponto de partida. Isso permite que as extensões adicionem seus novos recursos em novos repositórios, separados do projeto principal. O modelo deve fornecer a mesma estrutura modular que o repositório principal e incluir o framework para empacotar e lançar as extensões.

     • Certifique-se de que, à medida que o repositório principal muda, os modelos sejam conservados. Os mantenedores do repositório principal são responsáveis por atualizar os modelos para garantir que sejam compatíveis com o projeto principal. Seguir boas práticas de versionamento, como semver, torna isso mais fácil de seguir.

     • É recomendável ainda que os mantenedores do repositório principal forneçam orientações sobre como atualizar extensões com base em versões mais antigas do modelo à medida que novas versões são lançadas.

   • Adicione exemplo(s) de extensão desenvolvida(s) a partir do modelo, que os desenvolvedores do projeto podem usar como referência para entender como escrever uma extensão bem estruturada.

   • Flexibilize os requisitos para que os contribuidores criem extensões, permitindo a liberação mais rápida ou experimentação ao contornar revisões.

2. Acoplamento flexível: Ter componentes modulares que contenham funcionalidades pode permitir um acoplamento flexível, onde as alterações nas extensões não afetam a qualidade do código principal ou de outras extensões.

3. Gerenciamento de dependências: Cada extensão deve ser cuidadosa ao fixar a faixa de versão do repositório principal com o qual ela é construída (da mesma forma que faria com qualquer outra dependência) e deve ser cuidadosa em seu uso de outras dependências que possam sobrescrever dependências do repositório principal, de forma que as versões escolhidas para essas dependências sejam compatíveis com as versões selecionadas do repositório principal. Quaisquer conflitos com o repositório principal serão detectados no framework de teste da extensão.

4. Estratégia de testes: Como testar extensões individualmente e em combinação?

   • Testando extensões individualmente: O modelo de extensões fornecerá um framework de teste a ser usado pelos desenvolvedores de extensões para testar a capacidade adicionada. Isso pode incluir um framework para testes de unidade, testes de desempenho em tempo de execução e testes de qualidade.

   • Testando extensões em combinação com o repositório principal: Os desenvolvedores de extensões têm um método bem estruturado para testar suas extensões em relação a versões específicas do repositório principal sem envolvimento dos mantenedores do repositório principal.

   • Testando extensões em combinação com outras extensões: Fornecer um framework de teste para esse cenário pode ser excessivo, especialmente se houver um grande número de extensões que ainda estão sendo exploradas pelos usuários e é improvável que todas sejam usadas em combinação. Se um usuário encontrar conflitos ao usar extensões em combinação (o que deve ser improvável com um acoplamento suficientemente flexível), o usuário pode levantar um problema com os proprietários da extensão correspondente, que resolverão a situação. Conforme uma extensão atinge fases posteriores do ciclo de vida e é mesclada no repositório principal, ela será testada em combinação com o restante da biblioteca e quaisquer conflitos de dependência terão que ser resolvidos na época.

5. Descoberta e Usabilidade:

   • Torne as extensões facilmente descobríveis com uma página de publicação mostrando as extensões que os usuários criaram e desejam compartilhar para uso de produtos.

   • Permita o registro de extensões no projeto principal para que os usuários possam aproveitar as extensões junto com o projeto original, mantendo a mesma experiência do usuário.

6. Ciclo de vida das extensões e manutenção: Estabeleça o ciclo de vida das extensões, desde a criação até a migração para o código principal, juntamente com diretrizes claras de propriedade.

   • Os criadores das extensões continuam a manter a extensão, fornecendo suporte e correção de defeitos. Qualquer extensão não mantida será retirada da página de publicação.

   • Crie critérios para quando uma extensão pode ser migrada para o repositório principal, como a adoção da extensão por produtos internos e a demanda por recursos.

   • O processo de migração da extensão para o repositório principal seguirá diretrizes mais rigorosas de revisão de código estabelecidas pelos mantenedores da biblioteca.

Seguir esses princípios garante que:

• Os desenvolvedores podem adicionar novos recursos ao ecossistema de um projeto sem precisar escrever grandes quantidades de código boilerplate.

• As extensões são facilmente descobertas de maneira repetitiva por todos os usuários do projeto principal; apenas porque o código não está no repositório principal não significa que ele não seja valioso.

• A carga dos mantenedores é reduzida até que uma extensão tenha demonstrado que preenche uma lacuna importante no projeto principal.

• O código comum do projeto principal (por exemplo, classes base e funções de utilidade) pode ser um ponto de partida para novos desenvolvimentos que ampliam o domínio do projeto. Isso evita a necessidade de portar o trabalho inovador após o fato, reduzindo assim a carga geral de desenvolver recursos inovadores para o projeto.

• Os desenvolvedores têm mais probabilidade de contribuir e se envolver na manutenção e na construção de comunidades para sua base de código, o que também é benéfico para a saúde do ecossistema geral do projeto.

Contexto Resultante

• O projeto é capaz de dimensionar com a adição de novos recursos, sem adicionar sobrecarga de manutenção ao repositório do projeto principal.

• Lançamento mais rápido de novos recursos para a comunidade explorar, incentivando a inovação e experimentação.

• Redução do custoso processo de revisão de código e consolidação de recursos até que o recurso seja capaz de provar sua utilidade. Isso tem benefícios de economia de custos para a organização.

• Um problema pós-introdução que pode surgir - o que acontece se uma extensão não conseguir completar o ciclo de vida inteiro?

  • Se uma extensão não for adotada ao longo do tempo e não conseguir criar uma comunidade para apoiar sua manutenção, caberá ao proprietário da extensão continuar a mantê-la pelo tempo que desejarem. Se uma extensão não for mantida, será retirada da publicação.

  • Se um desenvolvedor de extensão não puder mais manter seu projeto e outros desenvolvedores na comunidade desejarem continuar a oferecer suporte, eles podem manter a extensão no futuro.

Instâncias Conhecidas

• IBM Corporation adotou essa solução para dimensionar bibliotecas de IA InnerSource. Usando extensões, os desenvolvedores podem ampliar as bibliotecas de IA com mais algoritmos e compartilhar suas inovações com a comunidade interna da empresa. As bibliotecas principais contêm apenas algoritmos estratégicos que foram adotados e validados, tornando mais fácil mantê-las à medida que ampliamos as contribuições.

Alias

Extensões para Gerenciar Contribuições em Escala

Estado

Structured

Autores

• Sukriti Sharma, IBM

• Alexander Brooks, IBM

• Gabe Goodhart, IBM

Histórico de Tradução

• 2023-10-26 - Tradução Eneri Junior

• 2023-10-26 - Tradução Humberto Zilio

Title

Ferramentas de Comunicação

Patlet

Os usuários de um projeto InnerSource têm dificuldade em obter ajuda e entrar em contato com a equipe responsável pelo projeto. Ao usar consistentemente ferramentas de comunicação assíncronas, o projeto torna as discussões visíveis, arquivadas e pesquisáveis, o que leva a um nível melhorado de suporte para os usuários.

Problema

Uma equipe está aberta a receber contribuições dos usuários downstream do seu componente. A coordenação e comunicação acontecem de forma ad-hoc, levando a informações incoerentes sendo compartilhadas, atrasos nas respostas recebidas, e os contributors contatando múltiplos membros da equipe anfitriã antes de receberem uma resposta definitiva.

Contexto

• Uma equipe depende do componente de outra equipe.

• Ela gostaria de fazer contribuições para esse componente.

• Mesmo quando a comunicação é feita por escrito, ela ocorre de forma individual.

Forças

• A equipe anfitriã está interessada em receber contribuições e disposta a orientar os colaboradores.

• As equipes têm uma forte cultura de comunicação verbal e têm pouca experiência em configurar canais de comunicação assíncronos específicos do projeto.

• Os canais de comunicação podem estar alinhados a grupos específicos que devem ser alcançados, mas não por objetivo de comunicação específico.

Solução

A equipe anfitriã deve fornecer canais de comunicação arquivados, pesquisáveis e vinculáveis ​​públicos da empresa, aos quais qualquer pessoa na empresa possa se inscrever, uma vez que existem benefícios mensuráveis ​​em apoiar canais de comunicação escritos e abertos.

O objetivo ao otimizar os canais de comunicação para projetos InnerSource deve ser alinhar a comunicação em torno de tópicos, não em torno de determinados grupos de pessoas.

Um projeto deve configurar as seguintes ferramentas de comunicação:

1. um issue tracker dedicado onde a comunicação estruturada, a tomada de decisões e o acompanhamento do progresso possam ocorrer de forma transparente para todos os membros da equipe anfitriã, mas também para os usuários e colaboradores downstream acompanharem. Para outras aplicações do issue tracker, consulte Issue Tracker Use Cases.

2. canal(is) de discussão pública que possuem uma estrutura menos rígida. Normalmente, isso será listas de e-mails, fóruns on-line, sistemas de perguntas e respostas ou até mesmo canais de bate-papo arquivados. Geralmente, é suficiente começar com apenas um canal para o projeto. Se o tráfego aumentar demais, é útil separar as discussões sobre o uso do projeto das discussões sobre o desenvolvimento do projeto.

3. um canal privado onde a comunicação sobre tópicos sensíveis possa ocorrer entre Trusted Committers - por exemplo, adicionando mais Trusted Committers à equipe anfitriã. Esse canal deve ser usado com muito cuidado, de modo que a comunicação padrão seja aberta e seja mantida privada apenas em circunstâncias muito raras.

While communication can happen outside of those written channels, as much information as possible should be brought back to the asynchronous channels.

All communication channels should be documented in the project README.md. For more details on the use of this file see Standard Base Documentation.

Embora a comunicação possa ocorrer fora desses canais escritos, o máximo de informações possível deve ser trazido de volta para os canais assíncronos.

Contexto Resultante

Configurar e utilizar consistentemente canais de comunicação assíncronos oficiais ajuda a criar um nível básico de documentação passiva que pode ser referenciado novamente quando surgirem perguntas semelhantes no futuro.

Com a comunicação acontecendo em aberto, outros podem facilmente acompanhar o progresso do projeto e se envolver ativamente contribuindo. Outras pessoas observando e lendo reduzem a barreira para se envolver, aumentando a probabilidade de receber contribuições.

Com perguntas sendo respondidas em público, mais pessoas podem adicionar suas perspectivas levando a uma imagem completa - isso inclui não apenas membros da equipe anfitriã, mas também usuários do projeto.

Manter a comunicação em canais assíncronos permite que os participantes com diferentes horários - seja devido a fusos horários diferentes ou devido a rotinas diferentes, horários de reuniões ou rotinas de equipe - contribuam significativamente para o projeto.

Responder perguntas nesses canais significa que não apenas outros membros da equipe podem ouvir e fornecer informações adicionais, mas também significa que outros usuários com a mesma pergunta veem (ou mais tarde encontram) a resposta anterior, levando a uma menor necessidade de repetir explicações.

Instâncias Conhecidas

• Europace AG

• Paypal Inc.

• Mercado Libre

Autores

Isabel Drost-Fromm

Reconhecimento

Sebastian Spier (for the visual)

Estado

• Structured

• Drafted in December 2019.

Créditos

People illustrations by Storyset

Histórico de Tradução

• 2023-04-20 - Tradução Eneri Junior

• 2023-04-20 - Tradução Humberto Zilio

Title

Garantia de 30 dias

Patlet

Ao aceitar contribuições de fora da sua própria equipe, há uma aversão natural em assumir a responsabilidade pelo código que não foi escrito pela própria equipe. Através da Garantia de 30 dias, a equipe contribuinte concorda em fornecer correções de bugs para a equipe receptora, o que aumentará o nível de confiança entre as duas equipes e torna mais provável que as contribuições sejam aceitas.

Problema

Uma equipe desenvolve um componente que é utilizado em toda a organização. Essa equipe resiste em aceitar ou rejeita completamente contribuições (pedidos de recursos). Esse comportamento bloqueia o progresso e leva a interrupções frequentes devido a escalonamentos.

Contexto

• As equipes dependem de outra equipe para aceitar suas contribuições para que um componente produzido pela equipe receptora possa ser utilizado pela equipe contribuinte.

• A equipe receptora não possui os recursos, conhecimento, permissão e/ou inclinação para escrever o componente/pedido de recurso por si própria.

Forças

• Existe desconfiança em relação às contribuições devido a um histórico de trapaças: equipes enviaram contribuições incompletas e posteriormente solicitaram correções para torná-las prontas para uso em produção.

• Se o código é contribuído por uma equipe externa, a equipe receptora tem a suspeita natural de que a outra equipe não sabe como escrever código que atenda às expectativas da equipe receptora.

• Cada equipe olha primeiro para ajudar seus próprios líderes a alcançar seus próprios objetivos. Essa direção de lealdade pode complicar a resolução desse problema.

• Existe uma aversão natural em assumir a responsabilidade pelo código não escrito por si próprio.

• O código contribuído precisa ser amplamente reescrito antes de ser aceito na base de código.

• Existe o medo de que os contribuintes não estejam disponíveis para dar suporte na correção de bugs após o tempo da contribuição.

• As equipes temem que o código contribuído levará a custos de manutenção altos (ou mais altos), mas não sabem como controlar isso.

• As equipes receptoras podem temer que ensinar outras pessoas a contribuir com o código irá expor dívida técnica em seu sistema e que essa visibilidade possa ser prejudicial.

• As equipes receptoras podem não acreditar que receberão um código aceitável, não importa quanto mentoria seja fornecida.

• Qualquer uma das equipes pode não se sentir confiante em medir riscos ou certificar que eles são mitigados em uma contribuição; o próprio sistema é um tanto frágil (pode não haver maneiras de testar completamente e detectar todos os problemas).

Solução

Aborde os medos tanto da equipe que recebe quanto da equipe que contribui, estabelecendo um período de garantia de 30 dias a partir do momento em que o código contribuído entra em produção. Durante este período de garantia, a equipe contribuinte concorda em fornecer correções de bugs à equipe receptora.

Observe que o período de garantia também pode ser de 45, 60 ou 100 dias. A duração pode variar com base nas restrições do projeto, no ciclo de vida do software do projeto, nos compromissos com os clientes e em outros fatores.

Além disso, ajuda a fornecer diretrizes claras de contribuição, especificando as expectativas da equipe receptora e da equipe contribuinte.

Contexto Resultante

• A equipe receptora está disposta a aceitar contribuições e é capaz de compartilhar a carga de trabalho de adaptações/correções iniciais.

• Aumenta a transparência e justiça.

• Evita que as escalações se tornem muito pesadas.

Instâncias Conhecidas

• Isso foi testado e comprovado com sucesso na PayPal.

• O GitHub internamente usa esse padrão com um prazo de garantia modificado de 6 semanas.

• A Microsoft recomenda esse padrão como um princípio - as equipes estabelecem seu próprio tempo específico, correspondendo às suas necessidades e confiança.

Autores

• Cedric Williams

Reconhecimento

• Dirk-Willem van Gulik

• Padma Sudarsan

• Klaas-Jan Stol

• Georg Grütter

Estado

• Structured

• Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.

Variações

• Assegurar a cooperação das equipes dependentes, tornando-as numa comunidade, através da nomeação de mais do que um "Trusted Committers" (TCs) por mérito próprio.

Histórico de Tradução

• 2023-04-13 - Tradução Eneri Junior

• 2023-04-13 - Tradução Humberto Zilio

Title

Gig Marketplace

Patlet

Estabeleça um mercado criando um site intranet que liste necessidades específicas de projetos InnerSource como "Gigs", com requisitos explícitos de tempo e habilidades. Isso permitirá que os gerentes entendam melhor o compromisso de tempo de seus funcionários e os benefícios profissionais, aumentando assim a probabilidade de obter a aprovação para fazer contribuições InnerSource.

Problema

Nem os gerentes nem os funcionários entendem como poderiam se beneficiar ao se envolverem em um projeto InnerSource.

É difícil para os funcionários comunicarem à sua gestão qual o compromisso de tempo que eles precisarão ter para um projeto InnerSource.

Os gerentes não têm uma maneira uniforme de acompanhar ou recompensar o envolvimento de seus funcionários em projetos InnerSource.

História

Você criou com sucesso um programa InnerSource em sua empresa e obteve o apoio da alta gerência, gerência intermediária e desenvolvedores. No entanto, após quase um ano, houve poucas contribuições reais para quaisquer projetos InnerSource fora das equipes que os criaram originalmente. Após entrevistar todas as partes envolvidas, o principal obstáculo parece ser que é difícil saber o compromisso de tempo que os desenvolvedores terão se optarem por se envolver em um projeto InnerSource e como se beneficiarão pessoalmente. Também não há uma maneira uniforme de anunciar quais oportunidades de contribuição existem, o que será solicitado e aproximadamente quanto tempo levará. Os gerentes são solidários e desejam que seus funcionários participem, mas até agora têm falta de uma maneira de contabilizar ou recompensar as atividades de seus funcionários dentro de projetos InnerSource. O que pode ser feito para melhorar esta situação para todas as partes envolvidas (proprietários de projetos InnerSource, possíveis contribuidores e gerentes de desenvolvimento)?

Contexto

Os funcionários gostariam de ter contato com atividades realizadas em outras áreas da empresa sem ter de deixar seus cargos atuais. Os projetos InnerSource existem e poderiam proporcionar essas experiências, mas há dois fatores principais que impedem os funcionários de participar. O primeiro é a incapacidade de descobrir facilmente quais são as oportunidades de contribuição existentes nos projetos InnerSource em andamento e de comunicá-las aos seus gerentes. O segundo é a incapacidade dos gerentes de planejar e contabilizar o tempo que seus funcionários dedicam a essas tarefas do projeto InnerSource. Como resultado, os proprietários de projetos InnerSource estão encontrando dificuldades para criar comunidades de tamanho suficiente para cumprir suas metas declaradas.

Forças

• Os funcionários não têm uma maneira fácil de descobrir as oportunidades existentes no InnerSource

• Os funcionários não entendem como a contribuição pode beneficiá-los profissionalmente.

• Os gerentes não entendem os requisitos de tempo/esforço associados às tarefas relacionadas ao projeto InnerSource.

Pré-requisitos

• Os funcionários têm recebido tempo de seus gerentes para se envolverem em projetos InnerSource.

• Os gerentes exigem uma forma de quantificar, rastrear e registrar as contribuições do InnerSource para que possam ser contabilizadas e recompensadas.

Solução

Crie um site de intranet baseado em "Gig", no qual os indivíduos possam anunciar suas habilidades e áreas de interesse e os proprietários de projetos InnerSource possam anunciar oportunidades de colaboração.

Os funcionários devem ser capazes de criar um perfil dentro do aplicativo no qual possam listar suas habilidades e áreas de interesse. O sistema deve aproveitar essas informações, informando proativamente os indivíduos (por e-mail ou por outros meios) quando for publicada uma vaga que corresponda a um ou mais desses critérios.

Cada Gig postada por um proprietário de projeto InnerSource deve incluir os requisitos estimados de habilidade e tempo para que possam ser facilmente combinados com um funcionário disponível e claramente comunicados à sua gerência direta. A descrição também deve incluir uma justificativa de como isso beneficiará a pessoa que assumir a tarefa, a fim de torná-la o mais atraente possível.

Um sistema baseado em pontos poderia ser criado para recompensar e rastrear o envolvimento de um funcionário em uma gig. Por exemplo, 10 pontos concedidos ao proprietário da gig por postar uma gig depois de concluída e 100 pontos para um desenvolvedor que concluir uma gig. Os pontos acumulados pela conclusão de Gigs poderiam ser usados como um mecanismo de gamificação e como critérios de gerenciamento de desempenho para obter informações sobre as áreas de especialização existentes em uma organização.

Aqueles que desejarem aceitar uma gig devem primeiro ser avaliados pelo proprietário da gig para determinar se o funcionário tem as habilidades necessárias e o tempo alocado por seu gerente para concluir a gig.

A transparência das contribuições feitas por meio de Gigs pode ajudar um colaborador a construir (ou diminuir) sua reputação, criando assim uma probabilidade maior de que a qualidade da contribuição seja alta. A conclusão de gigs também pode funcionar como prova de especialização em uma determinada área.

A natureza das gigs postadas no marketplace pode incluir habilidades técnicas e interpessoais, como a organização de um evento em grupo, a redação de um relatório ou solicitações de orientação etc.

O ideal é que a criação do Gig Marketplace seja assumida por uma equipe dentro de uma organização com a responsabilidade de fornecer infraestrutura e recursos para toda a empresa.

Contexto Resultante

O Gig Marketplace InnerSource aumentou enormemente o número de projetos InnerSource, bem como o número de funcionários envolvidos neles. A natureza autodirigida do Gig Marketplace aumentou a satisfação no trabalho entre os funcionários, permitindo-lhes um nível de escolha no trabalho que realizam e com quem podem fazer parcerias em toda a empresa. Os funcionários entendem exatamente no que estão se inscrevendo e o que podem esperar da experiência. Os gerentes têm mais condições de estimar e acompanhar os compromissos de tempo de seus funcionários com relação aos projetos do InnerSource, reconhecer seus esforços individuais e usar a conclusão de Gigs como uma forma de validar suas habilidades específicas. Os gerentes também podem aproveitar qualquer tempo ocioso que seus funcionários possam estar enfrentando, permitindo que eles se voltem para o trabalho disponível no Gig Marketplace. Os dados gerados pelas interações no Gig Marketplace também estão ajudando a orientar as decisões de contratação e treinamento em todos os departamentos.

Quando usado em combinação com o padrão do Portal InnerSource, o Gig Marketplace fornece um nível mais refinado de contexto e detalhes, além dos links para os repositórios de código e a documentação do projeto ao qual o Gig está relacionado.

Instâncias Conhecidas

• Uma grande organização de serviços financeiros usou a criação de um site do InnerSource Gig Marketplace para promover seu programa InnerSource.

• A SAP implementou o padrão Gig Marketplace - um novo programa InnerSource foi adicionado à plataforma interna de empregos, onde posições e ofertas semelhantes podem ser publicadas.

• Foi comprovado que o padrão Gig Marketplace funciona extremamente bem com o padrão associado [InnerSource Portal] (./innersource-portal.md) nesse contexto. O InnerSource Portal aumenta a conscientização sobre projetos específicos que estão em andamento, enquanto o Gig Marketplace anuncia tarefas de um determinado tipo disponíveis para serem trabalhadas nesses projetos.

Estado

• Structured

Autores

• Stephen McCall

• Shreyans Dugar

Histórico de Tradução

Title

Equipe Central

Patlet

Mesmo quando um projeto InnerSource é amplamente necessário, as contribuições e uso podem ser prejudicados porque o projeto é difícil de trabalhar. Estabelecer uma equipe central dedicada a cuidar dos itens fundamentais do projeto. O trabalho deles permite que os contributors adicionem e usem recursos que oferecem valor para seus cenários.

Problema

• É difícil contribuir para o projeto. Isso pode ser devido a coisas como:

  • Não é possível executar o projeto localmente.

  • Documentação insuficiente.

  • Código confuso.

  • Testes inadequados.

• É difícil usar o projeto. Algumas possíveis causas:

  • Documentação ruim (novamente).

  • Bugs frequentes.

  • Configuração não intuitiva.

História

Existe um projeto central do qual todos dependem. Que ótimo candidato para InnerSource! Infelizmente, o projeto cresceu organicamente, com várias contribuições e adições feitas de forma descuidada. Agora é uma massa espessa e confusa de código que ninguém entende e todos têm medo de tocar. É claramente necessário uma revisão completa (por exemplo, refatoração, testes, documentação, etc.), mas mesmo que todos precisem e queiram que esse trabalho aconteça, ninguém tira tempo para fazê-lo.

Contexto

• Muitas equipes precisam do projeto.

• O projeto tem uma dívida técnica significativa.

• Adoção e iteração lentas no projeto.

• Não há um proprietário ou mantenedor que assuma a responsabilidade pelo ecossistema de projeto e contribuição como um todo.

Forças

• Cada equipe contribuinte está ocupada e, portanto, prioriza o trabalho que resulta em um retorno imediato para si mesmos.

• Conforme o projeto cresce, a tendência natural é que ele se torne mais difícil de usar e modificar.

Solução

Forme uma equipe central cujo trabalho é manter este projeto em um estado para que outros possam facilmente aderir e contribuir para ele. Esta equipe central faz o trabalho necessário para um ecossistema de uso e contribuição saudável. Este trabalho crítico tende a não ser priorizado como uma contribuição. Categorias desse tipo de trabalho incluem comunicação, ambiente local e infraestrutura de DevOps.

Aqui estão alguns exemplos específicos:

• Bugs em produção

• Documentação

• Tutoriais e exemplos para integração de novos colaboradores

• Testes automatizados

• Integração e entrega contínua (CI/CD)

• Ambiente local de desenvolvimento

• Modularização

• Versionamento

• Monitoramento

• Desbravamento de novas classes/categorias de funcionalidades.

Cada um desses itens é muito importante para um ecossistema de produto saudável, mas é improvável que seja priorizado como uma contribuição.

A equipe central pode ser composta por um pequeno número de pessoas em tempo integral ou parcial. A escolha depende da quantidade de trabalho necessário, da disponibilidade de recursos e da cultura da organização. A consideração mais importante é formar a equipe de forma que permita que a organização a capacite e a responsabilize da mesma maneira que qualquer outra equipe.

Uma boa maneira de lembrar constantemente a equipe central desse objetivo é pedir que eles relatem regularmente sobre:

• número de equipes ativas que usam o projeto

• número de contribuições fora das equipes para o projeto.

O foco contínuo nesses indicadores naturalmente levará a equipe central a priorizar geralmente o trabalho correto para criar um ecossistema InnerSource próspero em torno do projeto.

Contexto Resultante

• O projeto é fácil de usar e contribuir.

• Muitas equipes usam e contribuem para o projeto.

• A equipe central tem o sucesso definido em termos da interação e resposta dos outros ao seu projeto.

Fundamentação

Separar uma equipe central e encarregá-la dessa forma ajuda a preencher as lacunas que um projeto de sucesso precisa, mas são deixadas para trás por contribuidores que estão perseguindo apenas sua própria agenda. A equipe central preenche essas lacunas e lubrifica as engrenagens para que o ecossistema de contribuição permaneça saudável.

Instâncias Conhecidas

• Nike implementou esse padrão para gerenciar o esforço de InnerSource em torno de seus pipelines de CI/CD reutilizáveis.

Estado

Structured

Autores

Histórico de Tradução

Title

Inicie como um Experimento

Patlet

Comece a sua iniciativa InnerSource como um experimento com limite de tempo para tornar mais fácil para os gestores que não estão familiarizados com o InnerSource endossar e apoiar a iniciativa.

Problema

Uma iniciativa InnerSource é considerada, mas não é iniciada porque a gestão está incerta sobre o resultado e, como resultado, não está disposta a comprometer um investimento.

Contexto

A empresa está considerando o InnerSource para aumentar a eficiência da colaboração em projetos de software. No entanto, a maioria dos gestores não está familiarizada com o modelo de trabalho de código aberto e está mais acostumada com o estilo de gestão hierárquica e de controle de cima para baixo. A ideia do InnerSource é muito popular entre os desenvolvedores de software da empresa, não apenas porque muitos desenvolvedores usam ou estão desenvolvendo ativamente software de código aberto.

Forças

• Os gestores vão querer validar as alegações de melhoria na colaboração por meio do InnerSource antes de fazer um investimento de longo prazo. Isso geralmente envolve medir as melhorias.

• Se a iniciativa InnerSource provavelmente terá uma grande adesão entre os desenvolvedores e se muitos projetos provavelmente dependerão dela, a decisão de encerrá-la será muito impopular e, portanto, difícil de ser tomada. A perda de controle percebida resultante pode desencorajar alguns gestores a sequer começar com o InnerSource.

• A implementação de modelos de trabalho no estilo InnerSource muitas vezes representa uma ruptura radical em relação aos modelos de trabalho praticados anteriormente. Portanto, é provável que processos obrigatórios existentes já não sejam aplicáveis e que processos de governança adequados estejam faltando. O resultado pode ser que seja necessário operar em uma zona de vácuo regulatória, às vezes legal. Exemplos são regulamentos relacionados a impostos e controle de exportações em grandes corporações com várias entidades jurídicas em diversos países.

Solução

Declare a Iniciativa InnerSource como um experimento com tempo limitado. Defina e comunique os critérios para os projetos ingressarem no experimento InnerSource. Escolha critérios que maximizem as chances de construir uma comunidade saudável. Um conjunto de critérios é bom se as percepções geradas a partir dele dentro do contexto do experimento puderem ser intuitivamente aplicadas a contextos envolvendo outros potenciais projetos InnerSource.

Exemplos de critérios são:

• Distribuição geográfica suficiente de desenvolvedores

• Mistura departamental suficiente de desenvolvedores

• Abertura da comunicação dentro da comunidade

• Caminho de carreira baseado em mérito dentro da comunidade

• Tomada de decisão democrática dentro da comunidade

Contexto Resultante

Os gerentes podem dar início ao InnerSource pelos seguintes motivos:

• A configuração experimental facilita a necessidade dos gerentes analisarem os números do programa InnerSource da mesma forma que fariam para projetos típicos.

• A possibilidade de falha do experimento é compreendida e aceita. O risco pessoal para os gerentes de apoio é minimizado.

• Mesmo em caso de falha, a configuração garante que a empresa aprenderá com o experimento.

• Em caso de sucesso, os dados coletados durante o experimento permitirão que os gerentes façam um compromisso mais duradouro com o InnerSource.

Os participantes no experimento InnerSource agora estão cientes de que devem provar à gestão que o InnerSource oferece os benefícios prometidos. Isso ajudará a focar o trabalho nas atividades que proporcionam o valor mais demonstrável, aumentando assim as chances de sucesso.

Finalmente, começar como um experimento torna muito mais fácil evitar regulamentos e forças, como políticas de ferramentas e processos, que poderiam diminuir as chances de sucesso.

Patterns Relacionados

Instâncias Conhecidas

• Robert Bosch GmbH (globally distributed software development)

Estado

• Structured

Autores

• Georg Grütter (Robert Bosch GmbH)

Reconhecimento

• Jason Zink (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

• Robert Hansel (Robert Bosch GmbH)

• Hans Malte Kern (Robert Bosch GmbH)

• Russ Rutledge (Nike)

• Tim Yao (Nokia)

• Clint Cain (Optum)

Histórico de Tradução

Title

Portal InnerSource

Patlet

Potenciais contribuidores não conseguem descobrir facilmente os projetos de InnerSource que lhes interessam. Ao criar um site de intranet que indexa todas as informações disponíveis sobre projetos de InnerSource, você permite que os contribuidores aprendam sobre projetos que possam interessá-los e que os proprietários de projetos de InnerSource atraiam um público externo.

Problema

Os times de projetos de InnerSource estão achando difícil atrair contribuições externas.

Os projetos de InnerSource em sua organização estão aumentando, mas os potenciais contribuidores não têm uma maneira fácil de descobri-los.

História

Você está tentando estabelecer uma prática de InnerSource dentro de sua organização. Você está ciente de que alguns projetos estão sendo executados usando um modelo InnerSource, mas sua existência é comunicada apenas por boca a boca, e-mail ou conversas laterais com outros funcionários. Como resultado, os proprietários de projetos de InnerSource estão achando difícil atrair contribuidores.

Não há um recurso único e compartilhado para os funcionários em toda a organização acessarem, que permita descobrir facilmente todos os projetos de InnerSource em andamento. Isso está limitando severamente o potencial de crescimento de cada projeto de InnerSource.

O que pode ser feito para ajudar todos os projetos de InnerSource a aumentar sua visibilidade para o maior público possível e atrair contribuidores em toda a organização?

Contexto

• Sua organização está interessada em adotar um estilo de trabalho InnerSource.

• Os proprietários de projetos de InnerSource estão procurando uma maneira de atrair audiências para seus projetos. No entanto, eles estão limitados pelos canais de comunicação disponíveis para eles, através dos quais poderiam anunciar para potenciais contribuidores.

• Os projetos de InnerSource em sua organização estão aumentando.

• Agravando esse problema está o fato de que o aplicativo compartilhado de gerenciamento de controle de código fonte em uso tem capacidades de pesquisa tão limitadas que até mesmo os desenvolvedores em busca de projetos de InnerSource acham frustrante localizá-los.

Pré-requisitos

• Os gerentes deram aceitação tácita de que seus funcionários devem participar de projetos de InnerSource.

• Um sistema compartilhado de gerenciamento de controle de código fonte está em uso, que fornece acesso programático ao conteúdo dos repositórios que hospeda.

• Há um departamento dentro de sua organização com a responsabilidade de promover a colaboração em InnerSource.

Forças

• O potencial completo das equipes de engenharia separadas de colaborar em desafios compartilhados não está sendo realizado.

• É difícil para indivíduos descobrir quais projetos InnerSource existem.

• É difícil para proprietários de projetos InnerSource atrair uma audiência de contribuidores externos.

Soluções

Crie um site de intranet de Portal InnerSource onde os proprietários de projetos InnerSource possam anunciar facilmente a disponibilidade de seus projetos.

As propriedades chave do portal são:

• Os visitantes do Portal InnerSource devem ser capazes de ver todos os projetos disponíveis, bem como buscar projetos específicos com base em vários critérios, como nome do projeto, tecnologias em uso, nomes de contribuintes, unidade de negócios patrocinadora, etc.

• As informações exibidas por meio do Portal InnerSource devem estar sob o controle total dos proprietários do projeto InnerSource em todos os momentos. Preferencialmente, obtendo essas informações diretamente de um arquivo de dados específico ou metadados armazenados no próprio repositório do projeto.

• Os proprietários do projeto devem incluir todas as informações relevantes sobre seus projetos nesses arquivos de dados, incluindo o nome do projeto, nomes dos contribuintes confiáveis, uma breve descrição e links para o repositório de código ou qualquer documentação de suporte. (opcional) Embora a maioria das organizações opte por tornar seu portal disponível apenas na intranet, algumas organizações escolheram disponibilizar seu portal na internet pública. Esta * última opção pode ser interessante para organizações que desejam mostrar informações adicionais sobre sua abordagem InnerSource em seu portal, por exemplo, para fins de marca e recrutamento.

Ao lançar o portal, deve-se considerar uma campanha de comunicação promovendo a adição de arquivos de dados ou metadados do InnerSource aos repositórios de código, a fim de aumentar o número de projetos exibidos no portal.

Contexto Resultante

• O Portal InnerSource permitiu que os proprietários de projetos InnerSource divulgassem seus projetos para um público em toda a organização. Devido a essa maior visibilidade, eles estão atraindo comunidades de contribuidores muito maiores do que nunca.

• Para aqueles que desejam se envolver em projetos InnerSource, o Portal InnerSource permitiu que eles descobrissem exatamente o tipo de oportunidades em que estão interessados, pesquisando simultaneamente todos os projetos InnerSource disponíveis com base em critérios específicos.

• Atender às necessidades desses dois públicos ajudou a estabelecer o InnerSource como uma opção viável e atraente para todas as áreas da organização aproveitarem para realizar coisas juntas que não poderiam ter feito separadamente.

Instâncias Conhecidas

• Uma grande organização de serviços financeiros utilizou a criação de um Portal InnerSource para fornecer um mecanismo de publicidade e descoberta de projetos InnerSource existentes em diferentes unidades de negócios.

• Elbit Systems utilizou esse padrão e adicionou gamificação por cima.
• Banco Santander criou um portal público chamado "Santander ONE Europe InnerSource Community" para apoiar e aumentar a adoção do InnerSource. Além do catálogo de projetos, o portal inclui conteúdo relevante, como documentação, forma de trabalho, notícias e eventos.

Referências

Estado

• Structured

Autores

• Stephen McCall

Reconhecimento

• Shelly Nizri

• Melinda Malmgren

• Michael Graf

• Jesús Alonso Gutierrez

Histórico de Tradução

Bem-vindo ao Livro de Padrões InnerSource.

Este livro contém as melhores práticas InnerSource codificadas em um formato específico para facilitar a compreensão, avaliação e aplicação delas em seu contexto. Chamamos esse formato de padrão.

A InnerSource Commons coletou esses padrões ao longo de muitos anos, publicando os padrões mais maduros neste livro, onde membros da comunidade revisam cada padrão, com pelo menos uma instância conhecida de uso do padrão.

Nesta introdução, explicamos o que é InnerSource, o que é um padrão e Como você pode usar Padrões InnerSource? em sua organização.

Se você já está usando InnerSource em sua empresa e deseja contribuir com suas experiências para este livro, adoraríamos receber suas contribuições!

O que é InnerSource?

Definimos InnerSource como:

O uso de princípios e práticas de código aberto para o desenvolvimento de software dentro dos limites de uma organização.

O InnerSource aproveita as lições aprendidas com o desenvolvimento de software de código aberto e as aplica à forma como as empresas desenvolvem software internamente. À medida que os desenvolvedores se acostumaram a trabalhar em software de código aberto de alta qualidade, surge um forte desejo de trazer essas práticas de volta para dentro da empresa e aplicá-las ao software que as empresas podem relutar em lançar.

Para empresas que constroem principalmente software de código fechado, o InnerSource pode ser uma ótima ferramenta para quebrar barreiras, incentivar e ampliar a colaboração interna, acelerar a integração de novos engenheiros e identificar oportunidades de contribuir com software para o mundo de código aberto.

O que são Padrões InnerSource?

Padrões são uma forma de descrever uma solução repetível e comprovada para um problema dentro de um contexto. Os padrões seguem uma forma simples que auxilia durante a implementação de uma solução para entender as restrições do problema, compreender as forças que você precisa equilibrar e o contexto resultante - a situação criada pela aplicação da solução.

Os padrões podem fornecer uma maneira para os participantes da InnerSource Commons compartilharem informações de forma concisa, melhorando a prática do InnerSource. Os padrões são divididos em Título, Declaração do Problema, Contexto, Forças e Soluções como suas principais seções.

• O que são padrões? Vídeos no Youtube - Assista a uma série de vídeos no Youtube de 2-5 minutos explicando Padrões InnerSource.

• Webinar de Discussão de Padrões - Realizamos um webinar em 16 de março de 2017 para discutir ao vivo um donut pattern (vá para 24:30 para a discussão). Isso ilustra o processo de revisão que seguimos. Veja também o Webinar O'Reilly de 1 de junho de 2017 sobre Padrões InnerSource.

• Modelo de Padrão - Veja um padrão InnerSource esqueleto para ter uma ideia do que é necessário para criar um novo padrão!

• Introdução aos Padrões InnerSource (apresentação do Fall Summit 2016) - Tim Yao e Padma Sudarsan (PDF). Fundo e exemplos detalhados de padrões - Entenda detalhadamente por que e como interagir com nossos padrões. Veja também a Introdução aos Padrões InnerSource (Fall Summit 2017) Tim Yao e Bob Hanmer (PDF).

Como você pode usar Padrões InnerSource?

Os padrões devem ser usados com cuidado. Eles não podem ser aplicados indiscriminadamente. Na maioria dos casos, você precisará adaptar a solução fornecida à sua situação; mas as informações dadas no padrão, definindo o contexto (restrições imutáveis) e as forças (restrições que podem ser alteradas e equilibradas entre si), devem ajudá-lo a fazer isso. Note que você também precisará determinar se existem restrições adicionais (contexto da empresa e forças da empresa) que se aplicam à sua empresa/organização específica e que devem ser adicionadas ao padrão (como um tipo de filtro). Essas restrições adicionais podem exigir etapas de solução adicionais a serem aplicadas.

A forma do padrão é útil para descrever soluções comprovadas, mas também pode ser usada para brainstorming de novas soluções onde os padrões ainda não estão estabelecidos. Isso ocorre porque a anatomia de um padrão fornece um framework para pensar em um problema de maneira estruturada. Você também pode criar um donut pattern (preenchendo os campos de problema, contexto, forças e contexto resultante, mas deixando a solução em branco) como uma maneira de pedir ajuda à comunidade da InnerSource Commons (para encontrar uma solução comprovada ou para gerar ideias para tentar).

Como Contribuir?

Por favor, consulte: Contribuir para este livro

Créditos

Este livro é o resultado de muitos anos de trabalho de inúmeros Contribuidores de Código Aberto de todo o mundo. Sua disposição em compartilhar abertamente os desafios que enfrentaram em suas empresas e como o InnerSource os ajudou a enfrentar esses desafios torna este livro um recurso valioso para outros em sua jornada InnerSource.

Queremos mencionar especificamente o Grupo de Trabalho InnerSource Patterns. Eles têm nutrido a qualidade dos Padrões InnerSource e ajudaram outros a contribuir. Por último, eles também compilaram uma seleção de padrões disponíveis neste livro.

A imagem de capa deste livro foi criada por Sebastian Spier e adaptada a partir de uma imagem de Tony Hisgett - Alhambra 6, disponível sob CC BY 2.0.

Obrigado a todos os contribuidores! E feliz Dia InnerSource :)

Licenciamento

InnerSourcePatterns por InnerSourceCommons.org está licenciado sob uma Licença Internacional Creative Commons Attribution-ShareAlike 4.0.

Title

Líder de Comunidade Dedicado

Patlet

Selecione pessoas com habilidades tanto em comunicação quanto em técnicas para liderar as comunidades e garantir o sucesso na iniciativa InnerSource

Problema

Como garantir que uma nova iniciativa InnerSource tenha o correto para aumentar seu impacto?

Selecionar as pessoas erradas e/ou não fornecer capacitação suficiente para elas pode acarretar em esforços desperdiçados e, em última análise, no fracasso de uma nova iniciativa InnerSource.

História

Considere a seguinte história. Uma empresa deseja iniciar uma iniciativa InnerSource para promover a colaboração entre as fronteiras organizacionais. Eles decidiram começar com uma fase experimental com escopo limitado. A gerência selecionou um tópico piloto adequado para a primeira comunidade do InnerSource e espera contribuições de muitas unidades de negócios da organização. A empresa nomeou um novo contratado para liderar a comunidade durante 50% do seu tempo de trabalho, pois ele ainda não estava 100% planejado. Após seis meses, a comunidade recebeu apenas algumas contribuições, a maioria delas de uma única unidade de negócios. A empresa substitui o líder da comunidade por alguém que tem um histórico mais longo na empresa, dessa vez por apenas 30% de seu tempo. Após mais seis meses, o número de contribuições aumentou apenas marginalmente. A empresa não está mais convencida de que o InnerSource ajuda a atingir sua meta de aumentar a colaboração entre divisões e abandona o InnerSource.

Contexto

• A empresa é uma empresa grande e antiga. Ela não tem experiência anterior em código aberto ou em outros modelos de trabalho baseados na comunidade. A cultura da empresa é mais bem caracterizada como um estilo clássico de gerenciamento de cima para baixo e, em geral, está em desacordo com a cultura da comunidade.

• Embora haja apoiadores e um patrocinador na gerência de alto nível, a gerência intermediária da empresa ainda não está convencida do InnerSource.

• A gerência não foi convencida a fornecer mais do que um orçamento limitado para financiar apenas um líder da comunidade em tempo parcial.

• O líder da comunidade inicialmente selecionado tem pouca ou nenhuma experiência anterior com o modelo de trabalho de código aberto.

• O líder da comunidade de desenvolvedores inicialmente selecionado não tem uma rede extensa na empresa.

Forças

Se uma empresa não investe significativamente na comunidade inicial de InnerSource em termos de orçamento e capacidade para InnerSource, a credibilidade de seu compromisso com InnerSource pode ser questionada. Um impulso comum de uma empresa com uma cultura de gestão tradicional diante de um projeto ou iniciativa que não esteja atendendo às expectativas é substituir seu líder. Fazer isso sem envolver a comunidade e seguir princípios meritocráticos ainda prejudicará o compromisso da empresa com InnerSource, destacando o atrito entre a cultura atual da empresa e a cultura almejada - uma cultura comunitária.

A contribuição de valor dos projetos InnerSource não será óbvia para muitos gerentes que estão imersos em métodos tradicionais de gerenciamento de projetos. Esses gerentes são menos propensos a designar um de seus principais funcionários, que geralmente são muito solicitados por projetos que não são InnerSource, para um projeto InnerSource por uma porcentagem significativa do tempo de trabalho deles.

A comunicação ocupa uma porcentagem significativa do trabalho diário de um líder da comunidade. Ao mesmo tempo, ele ou ela provavelmente também terá que liderar o desenvolvimento inicial. Diante de capacidade limitada, líderes inexperientes tenderão a se concentrar no desenvolvimento e negligenciar a comunicação. A barreira para potenciais colaboradores fazerem sua primeira contribuição e se comprometerem com a comunidade será muito maior se o líder da comunidade for difícil de alcançar ou demorar a responder a feedback e perguntas por falta de tempo. Além disso, líderes tecnicamente inexperientes provavelmente terão mais dificuldade para atrair e reter colaboradores altamente experientes do que um funcionário de destaque com alto grau de visibilidade dentro de uma empresa teria.

Se uma comunidade não consegue crescer rápido o suficiente e ganhar impulso, é provável que não consiga demonstrar de forma convincente o potencial do InnerSource.

Se a empresa selecionar um gerente de projeto ou de linha experiente imerso em métodos tradicionais de gestão para ser o líder da comunidade, é provável que ele ou ela se concentre em tópicos de gestão tradicional, como alocação de recursos, fornecimento de estrutura e canais de relatório, em vez de liderar pelo exemplo por meio de princípios meritocráticos. Isso minará a credibilidade da iniciativa InnerSource aos olhos dos desenvolvedores.

Solução

Selecione um líder da comunidade que:

• Possua experiência no modelo de trabalho em código aberto ou em modelos de trabalho comunitário similares.

• Tenha as habilidades interpessoais necessárias para atuar como líder natural.

• Lidere pelo exemplo e, assim, justifique sua posição na meritocracia da comunidade.

• Seja um excelente articulador de rede.

• Inspire os membros da comunidade.

• Seja capaz de se comunicar efetivamente tanto com a alta gestão quanto com os desenvolvedores.

• Seja capaz de lidar com os aspectos gerenciais do trabalho comunitário.

Empodere o líder da comunidade a dedicar 100% do seu tempo ao trabalho comunitário, incluindo comunicação e desenvolvimento. Informe a gestão sobre a necessidade de ser sensível às opiniões da comunidade ao engendrar uma mudança na gestão da comunidade. Idealmente, capacite a comunidade a indicar seu próprio líder.

Contexto Resultante

Um líder da comunidade com as propriedades descritas acima dará um rosto e incorporará o compromisso da empresa com o InnerSource. Isso tornará mais provável que outros associados em sua rede sigam seu exemplo e contribuam para o InnerSource. Com o tempo, ele ou ela poderá construir uma equipe central estável de desenvolvedores e, assim, aumentar as chances de sucesso para o projeto InnerSource. Ao convencer uma audiência grande o suficiente dentro de sua empresa sobre o potencial do InnerSource, ele ou ela fará uma contribuição importante para mudar a cultura da empresa em direção a uma cultura comunitária.

Ter líder da comunidade excelentes e dedicados é uma condição prévia para o sucesso do InnerSource. No entanto, não é uma solução mágica. Existem muitos desafios do InnerSource que vão além do que um líder da comunidade pode enfrentar, como desafios orçamentários, legais, fiscais ou organizacionais.

Instâncias Conhecidas

BIOS na Robert Bosch GmbH. Note que o InnerSource na Bosch teve como objetivo principal aumentar a inovação e, em grande parte, lidou com produtos voltados para uso interno. Esse padrão atualmente não é utilizado na Bosch por falta de financiamento.

Alias

Gerente de Comunidade Dedicado

Estado

• Structured

Autores

• Georg Grütter (Robert Bosch GmbH)

• Diogo Fregonese (Robert Bosch GmbH)

Reconhecimento

• Tim Yao

• Padma Sudarsan

• Nigel Green

• Nick Yeates

• Erin Bank

• Daniel Izquierdo

Changelog

• 2016-11-06 - 1st review

• 2017-04-06 - 2nd review

Histórico de Tradução

Title

Modelo de Maturidade

Patlet

As equipes começaram a adotar o InnerSource. A prática está se espalhando para vários departamentos. No entanto, a compreensão do que constitui um projeto InnerSource varia. A solução é fornecer um modelo de maturidade para permitir que as equipes realizem uma autoavaliação e descubram padrões e práticas das quais ainda não têm conhecimento.

Problema

Quando a adoção do InnerSource em uma empresa começa a aumentar, o acompanhamento individual de cada projeto por meio de um evangelista se torna inviável. Além disso, cada vez mais pessoas estão adquirindo pelo menos uma compreensão básica do que significa trabalhar em um projeto InnerSource. No entanto, ao observar todos os projetos InnerSource, a profundidade de compreensão do conceito divergirá. As equipes podem não estar cientes de padrões comprovados que as ajudariam a avançar para o próximo nível e a resolver problemas e pontos de dor com os quais estão lidando.

Contexto

Diversas equipes começaram a adotar práticas de InnerSource. O nível exato de compreensão da prática varia entre as equipes. Os problemas específicos com os quais as equipes se deparam divergem dependendo do contexto e ambiente de trabalho de cada equipe. Como resultado, a definição do que são práticas recomendadas importantes em um projeto InnerSource difere conforme cada equipe.

Forças

As equipes que compartilham aprendizados sobre InnerSource enfrentam mal-entendidos, pois não têm consciência do nível respectivo de adoção do InnerSource.

As equipes acreditam que "tudo se resume a migrar para um ambiente de desenvolvimento de software compartilhado " (GitLab, GitHub ou Bitbucket são exemplos bem conhecidos dessas forjas).

As equipes não têm conhecimento das melhores práticas que as ajudariam a resolver problemas com os quais se deparam em suas atividades diárias.

Solução

Solicite às equipes que façam uma autoavaliação com base no modelo de maturidade proposto.

Transparência

Planos e Produtos

Os projetos InnerSource se beneficiam do planejamento transparente em toda a organização, permitindo que as partes interessadas compreendam melhor as decisões e as influenciem de maneira que possa ser seguida por outros.

• PP-0: Indivíduos e equipes não divulgam regularmente seus planos ou produtos para múltiplas partes interessadas. Não existem ações formais na organização.

• PP-1: Indivíduos e equipes dão visibilidade aos seus planos ou produtos para múltiplas partes interessadas antes de iniciá-los. Roadmap compartilhado.

• PP-2: Já existem roadmaps compartilhados com diretrizes claras e regras de contribuição onde as partes interessadas podem fornecer feedback. No entanto, isso não é padronizado em toda a organização e nem todos os projetos fornecem essas informações.

• PP-3: Os roadmaps são compartilhados por padrão e há um processo padrão e maneira homogênea de fazer isso em toda a organização no nível de cada projeto InnerSource. Isso contém regras claras para contribuir e influenciar no roadmap.

Processo e Ferramentas de Desenvolvimento

Os projetos InnerSource prosperam quando os contribuidores se tornam ativos e participam. Como resultado, tornar a contribuição mais fácil deve ser equilibrado com objetivos técnicos puros.

• DP-0: Cada equipe segue seu próprio processo de desenvolvimento e ferramentas. Eles não são definidos para compartilhar conhecimento e artefatos fora da equipe de desenvolvimento. Equipes de desenvolvimento isoladas.

• DP-1: As equipes de desenvolvimento usam repositórios de código compartilhados internamente. Algumas equipes desenvolvem seu próprio processo de Integração Contínua (CI), usando ferramentas de CI não corporativas ou padrão. Não há um processo de revisão de código definido, embora algumas equipes de projetos o façam internamente.

• DP-2: A organização patrocina e promove um repositório compartilhado para o conhecimento coletivo. Algumas equipes desenvolvem seu próprio processo de CI, usando ferramentas de CI corporativas. Existem ambientes de CI. Processo de revisão de código definido e usado por alguns projetos. Às vezes, a revisão de código é feita por membros externos da equipe.

• DP-3: A maioria das equipes desenvolve seu próprio processo de CI, usando ferramentas de CI corporativas. Existem ambientes de CI. Processo de revisão de código definido e usado. A revisão de código é feita por membros tanto internos quanto externos à equipe.

Decisões

Com o intuito de motivar os colegas a contribuir para trabalhos fora de suas equipes principais, eles precisam ter visibilidade no processo de tomada de decisão do projeto anfitrião - mas também sentir que suas vozes estão sendo ouvidas e valorizadas.

• DC-0: Os tomadores de decisão frequentemente retêm intencionalmente ou por acidente dados e recursos relacionados às decisões do projeto.

• DC-1: Materiais que fazem parte das práticas de tomada de decisão se tornam disponíveis para revisão após as decisões serem finalizadas.

• DC-2: As pessoas sentem que sabem sobre - e estão contribuindo para moldar - a maioria (mas não todas) das decisões importantes à medida que essas decisões estão sendo tomadas. Materiais que fazem parte das práticas de tomada de decisão estão disponíveis em marcos definidos do projeto.

• DC-3: As pessoas sentem que fazem parte de um processo compartilhado e padronizado para tomada de decisões coletivas, endossado pela organização. Materiais que fazem parte das práticas de tomada de decisão são continuamente acessíveis durante os processos de trabalho.

Recursos Úteis

Para atrair contribuidores, materiais de suporte úteis precisam estar facilmente acessíveis.

• RS-0: Indivíduos e equipes nem contribuem para, nem acessam um repositório compartilhado de conhecimento.

• RS-1: Indivíduos e equipes disponibilizam materiais do projeto para revisão interna após terem concluído o trabalho. Indivíduos e equipes compartilham recursos, mas em sistemas ou repositórios desconexos, fragmentados ou individualizados/isolados. Indivíduos e equipes compartilham recursos, mas não há uma compreensão comum ou compartilhada dos critérios usados para determinar se as informações são sensíveis ou não. Não "compartilham pensamentos com outros".

• RS-2: Indivíduos e equipes tornam os materiais relacionados ao projeto acessíveis a alguns membros das equipes de projeto de acordo com formatos e/ou protocolos claramente definidos e compartilhados. Indivíduos e equipes retêm dados e recursos sensíveis, fornecendo detalhes, contexto e escopo limitados.

• RS-3: Indivíduos e equipes tornam os materiais relacionados ao projeto amplamente acessíveis à organização - e possivelmente também fora da organização - de acordo com formatos e/ou protocolos claramente definidos e compartilhados. Indivíduos e equipes que devem reter dados e recursos sensíveis têm clareza sobre o que não estão compartilhando, e outros entendem por que esses materiais não estão disponíveis para eles.

Histórias

Quando se trabalha em equipes anfitriãs, os erros serão automaticamente amplamente visíveis. Para manter os níveis de contribuição elevados, a cultura corporativa precisa celebrar o fracasso como uma oportunidade de crescimento e aprendizado.

• ST-0: Indivíduos e equipes não compartilham sucessos nem falhas para que outros possam aprender.

• ST-1: Indivíduos e equipes se sentem à vontade para compartilhar histórias sobre sucessos, mas não sobre falhas.

• ST-2: Indivíduos e equipes se sentem à vontade para compartilhar histórias de sucessos e falhas durante retrospectivas e revisões.

• ST-3: Indivíduos e equipes se sentem à vontade para compartilhar histórias de sucessos e falhas, e aprendem com as falhas de acordo com protocolos formais.

Colaboração

Canais para Prover Feedback

Para reduzir silos, os colegas precisam se sentir à vontade para compartilhar feedback abertamente. Uma maneira fácil de apoiar isso é usar os mesmos princípios de comunicação em todas as hierarquias.

Idealmente, você acabará com canais de comunicação adequados que sejam conhecidos por todos na organização - com canais focados em diferentes objetivos (anúncios, suporte ao usuário, canais de desenvolvimento, discussões de infraestrutura, etc.). Algumas das melhores práticas que você estabelecerá à medida que seus projetos InnerSource amadurecem: Adoção de diretrizes de netiqueta, abertura de um conjunto comprovado de canais padrão (que estão sendo arquivados, acessíveis publicamente, pesquisáveis) para cada novo projeto InnerSource.

• CF-0: Não existem processos nem canais estabelecidos. Alguns membros da organização compartilham materiais por meio de canais ou discussões privadas.

• CF-1: A organização está no processo de estabelecer diretrizes internas e canais para incentivar pontos de vista diversos sobre decisões da empresa/departamentais, para que qualquer pessoa pertencente à organização possa usá-los. Alguns membros da organização compartilham materiais de tomada de decisão informalmente usando plataformas não oficiais. Líderes mantêm pelo menos um canal claro e direto para que os membros da organização compartilhem opiniões construtivas sobre alguns assuntos relevantes para o trabalho.

• CF-2: A organização estabeleceu diretrizes e canais internos, e fornece recursos específicos (programas de treinamento, acesso a conteúdo, etc.) para incentivar e solicitar pontos de vista diversos sobre decisões de equipe ou decisões em geral.

• CF-3: Membros da organização compartilham materiais de tomada de decisão em plataformas oficialmente sancionadas. Membros da organização compartilham materiais abertamente por meio de múltiplos canais e métodos para feedback. Líderes usam esses canais, encorajam abertamente outros a usá-los e mantêm registros voltados para a equipe ou públicos do feedback que receberam e/ou das ações que tomaram para abordar esse feedback.

Liderança

Projetos InnerSource incentivam os funcionários a contribuírem para projetos fora da influência direta de seu gerente direto. Isso requer uma cultura de confiança.

• LS-0: Cultura de comando e controle, dentro de uma organização altamente hierárquica.

• LS-1: Alguns líderes estão abertos a receber feedback e a criar um ambiente onde as pessoas se sintam seguras para fornecê-lo.

• LS-2: A maioria dos líderes na organização está aberta a receber feedback e a criar um ambiente onde as pessoas se sintam seguras para fornecê-lo. Os líderes demonstram passividade em entender se todos os membros se sentem capacitados e habilitados a compartilhar. A organização incentiva os líderes a buscarem ativamente vozes não presentes no diálogo para inclusão.

• LS-3: Os membros se sentem capacitados e habilitados a compartilhar opiniões construtivas sobre qualquer assunto relevante para o trabalho ou sobre o qual sintam paixão.

Estrutura Organizacional e Funcional

Quando o InnerSource sai do nível de codificação pura e entra no nível de comunidade e grupo de trabalho, existe o potencial para reduzir silos, mesmo onde a colaboração direta de código não é possível.

• OF-0: Grupos de trabalho tendem a ser estáticos em termos de membros e conjuntos de habilidades.

• OF-1: Existem equipes multifuncionais, mas os papéis da equipe muitas vezes são obscuros e as estruturas de governança são vagas.

• OF-2: Equipes multifuncionais são comuns e as equipes publicam seus papéis e objetivos abertamente.

• OF-3: Equipes multifuncionais são comuns e tornam suas atividades amplamente conhecidas pela organização; por sua vez, a organização promove as melhores práticas para trabalhar juntos.

Contribuição

O objetivo ao projetar padrões de contribuição precisa manter a colaboração em mente, se a intenção é reduzir silos.

• CB-0: Totalmente isolado, sem colaboração fora das equipes. Alguma colaboração ocorre devido a equipes multifuncionais.

• CB-1: Membros da organização e equipes colaboram, mas frequentemente afirmam que é "muito difícil". Equipes revisitam raramente os resultados de suas colaborações.

• CB-2: Membros da organização e equipes buscam ativamente oportunidades para colaborar. Equipes discutem, revisitam e debatem rotineiramente os resultados de seus esforços colaborativos e tornam esses resultados disponíveis por padrão.

• CB-3: Membros da organização colaboram interna e externamente de maneiras que beneficiam a todos os envolvidos. Equipes discutem, revisitam e debatem rotineiramente os resultados de seus esforços colaborativos, compartilham suas aprendizagens fora da organização e disponibilizam esses resultados externamente por padrão.

Comunidade

Políticas de Compartilhamento

Ter uma base de valores compartilhados facilita o trabalho entre as fronteiras das equipes. Cruzar essas fronteiras se torna mais fácil se um conjunto limitado de regras e diretrizes básicas se aplicar em todos os lugares e puder ser facilmente referenciado.

• SP-0: Nenhuma cultura de compartilhamento nem políticas escritas.

• SP-1: Alguns membros da organização se unem para definir valores e princípios, mas não recebem suporte claro ao fazerem isso.

• SP-2: Membros da organização documentam coletivamente visões e acordos compartilhados, como declarações de missão e códigos de conduta, tornam-nos facilmente acessíveis e os referenciam frequentemente. Materiais de integração e rituais de orientação fornecem contexto adequado para ajudar novos membros a entender como a organização se beneficiará de suas contribuições.

• SP-3: Valores e princípios compartilhados orientam processos de tomada de decisão, resolução de conflitos e avaliação entre os membros da organização, que referenciam consistentemente esses valores e princípios em formatos verbais e escritos.

Sentir-se parte da organização

Uma das possíveis razões para introduzir o InnerSource nas organizações pode ser o aumento do engajamento. Este ponto acompanha como o engajamento está mudando ao adotar o InnerSource.

• PA-0: Baixo engajamento, sem colaboração, e as pessoas não se sentem à vontade para compartilhar com os outros.

• PA-1: Membros da organização se sentem à vontade para compartilhar seus pensamentos e opiniões sem medo de retaliação, mas apenas em domínios familiares. As pessoas entendem que as melhores ideias vencem, e as responsabilidades de liderança se acumulam para as pessoas com histórico de contribuição e comprometimento.

• PA-2: Membros da organização se sentem à vontade para compartilhar seus pensamentos e opiniões sem medo de retaliação. Líderes demonstram dedicação aos valores compartilhados da organização.

• PA-3: A organização é proativa em dizer aos membros que se beneficia de suas contribuições; como tal, os membros demonstram consciência compartilhada e execução empoderada, e sentem um senso de responsabilidade para com a comunidade. Líderes entendem que crescem ao ajudar os outros a crescer, e eles mentoram membros juniores da organização.

Governança

Prémios

Para impulsionar a adoção, motivadores extrínsecos podem ser usados para aumentar a colaboração entre equipes.

• RW-0: Sem recompensas.

• RW-1: Líderes são incentivados a recompensar colaborações excepcionais, mas não há políticas ou processos estabelecidos.

• RW-2: Processos padrão são estabelecidos para recompensar colaborações fora das equipes de desenvolvimento. Líderes de equipe ou conselhos decidem quem deve ser recompensado.

• RW-3: Recompensas não são apenas propostas pela organização, mas as comunidades podem definir suas recompensas mais valiosas. A comunidade é responsável por decidir quem deve ser recompensado.

Políticas de Monitoramento

Projetos InnerSource precisam de um meio para autoavaliação. Métricas podem ser um aspecto para facilitar essa avaliação. Além disso, em organizações com um nível de adoção maduro do InnerSource, esperamos que a adoção do método seja rastreada com base em métricas claras e acordadas.

• MP-0: Não existem políticas de monitoramento existentes em nenhum nível da organização.

• MP-1: Métricas são importantes para certas equipes, e elas começam a usá-las de maneira isolada.

• MP-2: Existe uma estratégia em nível organizacional em relação às métricas que ajudam a validar políticas específicas em toda a organização. Essa política de monitoramento existe em nível de alguns projetos InnerSource.

• MP-3: Existem diretrizes claras, recomendações e treinamentos sobre o uso de métricas com infraestrutura específica fornecida pela organização. Isso funciona em ambos os níveis: programa InnerSource para entender a adoção geral do InnerSource dentro da organização e no nível dos projetos InnerSource.

Apoio e Manutenção

Não apenas o desenvolvimento de recursos deve ser de responsabilidade das equipes InnerSource - o suporte e a manutenção também fazem parte das tarefas principais das equipes.

• SM-0: Suporte fornecido pela equipe principal de desenvolvimento ou equipe de suporte. Um contrato comercial garante o suporte. Não há conhecimento sobre o produto fora da equipe.

• SM-1: Existem regras e regulamentos para formalizar o suporte ao produto, fornecido por uma equipe de suporte dedicada.

• SM-3: Existem regras e regulamentos para formalizar o suporte ao produto, fornecido por uma comunidade madura.

Cultura

Existem vários níveis em direção a uma cultura colaborativa.

• CL-0: Silos - equipes trabalham independentemente, mas também em isolamento.

• CL-1: Reativo - equipes trabalham independentemente, mas sabem como reagir a falhas nas dependências.

• CL-2: Contributivo - equipes ajudam ativamente a melhorar suas dependências contribuindo.

• CL-3: Ativista - equipes buscam ativamente ajuda, orientam e recrutam novos contribuidores.

Papéis InnerSource

InnerSource traz consigo papéis explícitos. Enquanto nas primeiras etapas alguns padrões podem ser utilizados sem adotar esses papéis, a comunicação dentro dos projetos usando títulos de papel explícitos se torna mais fácil.

• RO-0: Não existem papéis específicos que auxiliem a adoção do InnerSource. Apenas papéis de desenvolvimento comuns estão presentes: desenvolvedor, analista, testador, etc.

• RO-1: Ocasionalmente, alguns indivíduos e equipes contribuem para outros projetos. Essas são contribuições técnicas, onde o papel de usuário/contribuidor é reconhecido. Para algumas equipes, pode ser identificado pelo menos um membro que é uma referência técnica, explicando o processo de desenvolvimento a outros membros da equipe de desenvolvimento. Essa pessoa poderia ser candidata a cobrir o papel de trusted committer.

• RO-2: Um papel de Oficial de InnerSource é responsável pela governança e suporte, incluindo processos, etc. Identifica as necessidades de educação e garante que sejam providenciadas para a organização. Lidera e orienta a organização no envolvimento em projetos InnerSource. É o primeiro passo formal no caminho, definindo a visão e o roteiro do InnerSource. A organização definiu um papel de trusted committer, que é um ponto de contato/referência não apenas para membros da equipe de desenvolvimento, mas também para contribuidores externos. Existe um processo padrão que descreve como contribuir para a comunidade, o papel de contribuidor está presente. O papel de Cientista de Dados é responsável por gerenciar os rastros de atividade deixados pela iniciativa InnerSource, necessários para medir a evolução do InnerSource. O papel de trusted committer evoluirá para um perfil mais técnico, e um Gerente de Comunidade será responsável por "energizar" a comunidade, sendo sua principal responsabilidade atrair e reter novos desenvolvedores/usuários (contribuidores/membros da comunidade).

• RO-3: Evangelistas estão se movimentando dentro da organização, para informar os outros sobre o trabalho atual, o que o InnerSource faz e como fazê-lo, e ajudar os outros a entenderem e se tornarem parte da iniciativa. Contribuidores não técnicos aparecem.

Contexto Resultante

Todos as equipes têm conhecimento das melhores práticas disponíveis.

As equipes compreendem seu nível de adoção do InnerSource.

Antes de adotar o InnerSource como um modelo de trabalho, as equipes têm ciência das práticas que se espera delas - tanto a curto prazo quanto a longo prazo.

Instâncias Conhecidas

• Entelgy

• Zylk

• Bitergia

Autores

• Daniel Izquierdo Cortazar

• Isabel Drost-Fromm

• Jorge

• Nerea

Reconhecimento

• Alexander Andrade (um agradecimento especial pela correção ortográfica)

Alias

Modelo de Maturidade: Conheça as Melhores Práticas do InnerSource

Estado

• Structured

• Drafted in September 2019

Histórico de Tradução

Title

Processo de Liberação Padrão

Patlet

As equipes podem hesitar em adotar um projeto InnerSource se não tiverem certeza de sua maturidade. Para abordar isso, notas de lançamento consistentes e artefatos publicados são cruciais. Essas práticas demonstram um compromisso sólido com o projeto, transmitindo confiança e garantindo aos usuários o comprometimento contínuo com software sustentável e bem gerenciado.

Problema

Quando uma equipe está decidindo se deve usar um projeto InnerSource, uma de suas considerações é se podem contar com o projeto fornecido por um período prolongado. Mudar as ferramentas/projetos que estão usando tem um custo, portanto, eles só desejam fazer esses investimentos quando for necessário e houver benefícios tangíveis.

É prática comum em projetos de Código Aberto ter lançamentos versionados, com notas que documentam mudanças que quebram a compatibilidade e novos recursos, juntamente com uma binário publicado ou um link para uma imagem Docker. Essa prática pode não ser tão transparente ou bem documentada/visível para projetos InnerSource, módulos, etc.

Projetos InnerSource que não possuem um artefato publicado ou um processo de lançamento reduzem a confiança. As equipes não saberão quando esperar o próximo lançamento, quando mudanças que quebram a compatibilidade forem introduzidas, etc.

Contexto

Grandes organizações produzem muitos softwares internos, grande parte dos quais poderia ser reutilizada por equipes em toda a empresa. Ferramentas operacionais, bibliotecas de software e módulos de infraestrutura como código (IaC) são exemplos comuns desse tipo de software. No entanto, a maioria das grandes organizações não publica softwares internos para serem consumidos por outras equipes na empresa. Isso pode ocorrer porque estão ocupados demais para fornecer documentação ou não percebem o valor dos projetos para os outros.

Deveria estar disponível um repositório de código-fonte interno ou público onde o código-fonte é armazenado, mas as equipes não têm um processo para tornar o software consumível por outras equipes.

À medida que uma organização cresce e mais software interno é escrito, o valor desse padrão aumenta.

Forças

Difícil para organizações que não têm um sistema CI/CD centralizado

Para organizações que não fornecem aos engenheiros um sistema CI/CD centralizado, automatizar o processo de compilação e lançamento pode ser desafiador. A equipe pode precisar implementar sua própria ferramenta (Jenkins, Drone, etc). Sem um sistema CI/CD, as compilações e notas de lançamento ainda podem ser produzidas, no entanto, isso pode exigir uma compilação local do software e o upload manual para a ferramenta que hospeda os artefatos de compilação.

Carga adicional de publicar notas de lançamento

Além de compilar o código-fonte, escrever notas de lançamento pode ser tedioso sem a capacidade de gerar automaticamente uma lista de commits do Git. Isso ficaria a cargo de alguém fazer manualmente, além de escrever detalhes em um nível mais alto sobre o lançamento.

Dificuldade aumentada sem um local para hospedar artefatos

Se uma empresa não fornece um local centralizado para armazenar artefatos de compilação (jars, módulos npm, etc.) e imagens Docker, os engenheiros podem ser deixados por conta própria para decidir onde é apropriado armazenar o software versionado. Ferramentas como o GitHub oferecem isso, no entanto, se uma empresa não estiver usando uma dessas ferramentas populares, isso pode representar uma dificuldade.

Solução

Fornecendo notas de lançamento claras e um artefato publicado, você aumenta a confiança das pessoas de que está publicando um produto de qualidade no qual podem confiar.

Os seguintes são elementos-chave para alcançar isso:

• Um pipeline de CI/CD está localizado dentro do seu repositório que automatiza o processo de lançamento

• Os artefatos de compilação são gerados pelo sistema de CI/CD (binário, imagem Docker, jar, etc)

• Os lançamentos são claramente rotulados e marcados com versionamento semântico

• Os lançamentos incluem notas sobre Novos Recursos, Correções de Bugs e quaisquer "Mudanças que Quebram"

Um bom exemplo de notas de lançamento de qualidade pode ser encontrado aqui.

Contexto Resultante

As equipes que encontrarem o seu projeto verão notas de lançamento publicadas e ganharão confiança em sua ferramenta. Artefatos publicados também facilitam e aceleram a adoção do seu produto. Ter processos bem definidos e visíveis, como esses, também ajuda na colaboração entre equipes e com novos contribuidores. As pessoas podem ter confiança de que suas contribuições serão disponibilizadas e distribuídas em um tempo razoável, com um caminho de uso claro.

As notas de lançamento também são uma ótima oportunidade para elogiar os participantes! Como sabemos, a documentação é extremamente importante para novas pessoas que desejam se envolver com o seu projeto. Elogiar colegas de outras equipes por suas contribuições, incluindo documentação e notas de lançamento, é uma ótima maneira de fomentar a comunidade e expandir sua base de usuários.

Instâncias Conhecidas

• Comcast (vários projetos)

• GitHub (vários projetos)

Autores

David Grizzanti

Estado

Structured

Histórico de Tradução

• 2023-10-26 - Tradução Eneri Junior

• 2023-10-26 - Tradução Humberto Zilio

Title

Serviço vs. Biblioteca

Patlet

Equipes em um ambiente DevOps podem relutar em trabalhar além dos limites de suas equipes em bases de código comuns, devido à ambiguidade sobre quem será responsável por responder a interrupções de serviço. A solução é perceber que muitas vezes é possível implantar o mesmo serviço em ambientes independentes com cadeias de escalonamento separadas no caso de interrupções de serviço, ou separar grande parte do código compartilhado em uma biblioteca única e colaborar nela.

Problema

Quando as equipes estão trabalhando em um ambiente DevOps, os desenvolvedores são responsáveis por um recurso do início ao fim: desde o cliente até a implantação, manutenção e suporte. Isso representa um desafio ao trabalhar além dos limites da equipe: as cadeias de escalonamento podem não ser as mesmas para erros que ocorrem em qualquer equipe. O acoplamento entre código-fonte e implantação deixa as equipes com a dúvida de quem é responsável pelo suporte de plantão em caso de erros. Como resultado, as equipes relutam em unir forças, mesmo que haja uma sobreposição significativa nos requisitos.

Contexto

• As equipes estão trabalhando em um ambiente de micro-serviços.

• Elas estão organizadas em equipes de DevOps totalmente funcionais: Cada equipe é responsável por suas contribuições do início ao fim, incluindo manutenção, suporte de plantão e suporte ao cliente.

• Uma equipe tem a tarefa de fornecer um serviço aos seus clientes downstream que é bastante semelhante a um serviço existente construído por outra equipe.

Forças

• Os caminhos de escalonamento organizacional podem ser diferentes para cada uma das equipes.

• Os membros de cada equipe podem estar relutantes em fornecer suporte de plantão para erros que não afetam seus próprios clientes downstream.

• Os níveis de gravidade para os mesmos tipos de erros podem ser diferentes entre as fronteiras das equipes devido a diferentes definições de SLA por equipe/relacionamento com o cliente.

• As equipes podem ter diferentes restrições de segurança ou regulamentações que regem suas implantações.

Solução

Separar a responsabilidade pelo código-fonte da implantação: Ambas as equipes trabalham para identificar exatamente onde existem sobreposições e sinergias.

Apenas o código-fonte partilhado é mantido como parte do projeto InnerSource com responsabilidade partilhada. O código-fonte partilhado deve ser coerente, na medida em que inclui todo o código de teste (incluindo testes de integração, se disponíveis) e o máximo possível do pipeline de CI para facilitar a validação da contribuição.

Separe os pipelines de configuração e implantação da lógica comercial real. Estabelecer uma segunda implantação do serviço para a segunda equipe.

Tratar a base comum como uma biblioteca que é utilizada por ambas as equipes com código partilhado propriedade partilhada.

As configurações de implementação podem ser incluídas como projectos separados no seu portfólio InnerSource para permitir que as equipes discutam/colabore ou que uma nova equipe as copie.

Contexto Resultante

As equipes estão dispostas a colaborar, se beneficiando ao compartilhar o trabalho de implementação da lógica de negócios.

Um serviço que originalmente foi construído especificamente para funcionar em um ambiente é convertido em uma solução mais geral com base em um requisito de negócio específico.

Ambas as equipes conhecem sua respectiva política de escalonamento e configuração de implantação, identificando potencialmente melhorias para sua própria configuração.

A probabilidade de que mudanças sejam necessárias e feitas no código-fonte compartilhado aumenta, levando a oportunidades mais frequentes de refinar, melhorar e otimizar a implementação.

Estimula a padronização operacional incremental no empacotamento de lançamento, telemetria, endpoints de saúde/preparação e assim por diante, à medida que as equipes percebem que podem manter isso de maneira mais eficiente no código compartilhado se concordarem com convenções padrão.

Veja também

Relacionado a este padrão está o Garantia de 30 dias, que adota uma abordagem diferente para lidar com as forças descritas acima.

Instâncias Conhecidas

• Europace AG

• Flutter Entertainment: Flutter InnerSource application possui um repositório de código compartilhado "service" com contribuições entre equipes e uma pipeline de CI para construir e publicar um artefato de release compartilhado. Cada equipe adotante possui um repositório de "configuração de implantação" que define sua própria implantação. Isso é conduzido por diferentes requisitos regulatórios, práticas de gerenciamento de serviço e incidentes e conjuntos de habilidades de infraestrutura em diferentes áreas do negócio.

Estado

• Structured

Autores

• Isabel Drost-Fromm

• Rob Tuley

Reconhecimento

Obrigado, Tobias Gesellchen, pela revisão interna na Europace AG.

Alias

Serviço vs. Biblioteca: É Inner Source, Não implantação interna

Histórico de Tradução

• 2023-08-20 - Tradução Eneri Junior

• 2023-08-20 - Tradução Humberto Zilio

Title

Suporte em Grupo

Patlet

O que acontece se uma equipe ou indivíduo não suporta mais um projeto InnerSource? Mantenha o projeto vivo formando um grupo de indivíduos interessados.

Problema

• Um projeto InnerSource popular está órfão.

• Não há um destino óbvio para ele.

História

Uma biblioteca de widgets de interface do usuário é usada por mais de 50 projetos em toda a empresa. O financiamento da equipe que é proprietária da biblioteca se esgota e a equipe se dissipa. No início, ninguém percebe, mas depois de um tempo, sempre que alguém pergunta "quem é o responsável", não há uma resposta. O que acontecerá em seguida? As novas equipes evitarão usá-lo? O projeto estagnará e permanecerá até que seus usuários eventualmente sejam forçados a migrar para outra solução? Que pena se isso acontecer a um projeto perfeitamente bom e útil!

Contexto

• Projeto InnerSource popular.

• Consumido como uma dependência de tempo de compilação (por exemplo, módulo de código).

• Ninguém está oferecendo suporte ativamente.

• A empresa não pode alocar uma equipe para oferecer suporte.

Forças

• Ninguém é designado por seu trabalho diário para trabalhar nele.

• Todos estão ocupados.

• Alto custo para migrar do projeto.

Solução

Chamar voluntários interessados de qualquer parte da empresa para formar um grupo de Trusted Committers para oferecer suporte ao projeto. Você pode precisar entrar em contato com indivíduos específicos com base no histórico de commits ou uso. É importante que haja pessoas suficientes para que a carga sobre cada uma seja razoavelmente pequena.

Ao formar este grupo, ele deve identificar ou criar Standard Base Documentation e Communication Tooling.

O grupo deve fazer o melhor para gerenciar esses aspectos do projeto:

• Manutenção. Se o projeto estiver completamente quebrado para o caso de uso padrão, então conserte-o. Mantenha o projeto atualizado à medida que as dependências e estruturas que ele usa continuam a evoluir.

• Integração. Se alguém tiver uma pergunta sobre como usar o projeto, certifique-se de que eles obtenham uma resposta razoável.

• Atualizações. Se alguém desejar adicionar um novo recurso ao projeto, forneça o suporte de design e técnico necessário para que eles o construam, de modo que funcione para eles e seja uma boa adição ao projeto. Revise as solicitações de pull que chegam de forma oportuna.

Uma vez que este grupo é composto por voluntários, é importante comunicar que o suporte é "melhor esforço" apenas. Portanto, este modelo de suporte não é adequado para projetos críticos em tempo de execução, como APIs em produção. Ele é mais adequado para projetos que são consumidos no momento de compilação, como bibliotecas/pacotes/módulos. Não se espera que o grupo implemente qualquer nova funcionalidade para outros.

Contexto Resultante

• Existe algum suporte frágil para o projeto InnerSource.

• A longo prazo, é provável que o suporte do grupo se dissolva novamente em algum momento. Se o projeto continuar a longo prazo, aproveite este período de suporte estável do grupo para encontrar uma maneira duradoura de suportá-lo (por exemplo, Core Team).

Justificativa

As pessoas geralmente querem ajudar. Se houver uma abordagem pessoal para que alguém se junte como um Trusted Committer, geralmente haverá várias pessoas que dirão "sim". Sentir-se parte de um grupo e ser atribuído a alguma estrutura e responsabilidade geralmente motiva as pessoas a fazer o seu melhor, o que muitas vezes acaba sendo suficiente.

Instâncias Conhecidas

• WellSky

Estado

Structured

Autores

Russell R. Rutledge

Histórico de Tradução

• 2023-10-26 - Tradução Eneri Junior

• 2023-10-26 - Tradução Humberto Zilio

Title

Short Title Here

Patlet

Concise 1-2 sentence description of the problem and solution. Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns. From http://wiki.c2.com/?PatLet

Problem

What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.

Story (optional)

Sometimes there is a story that helps people understand the pattern better.

Context

Where does the problem exist? What are the pre-conditions? Unchangeable before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"

Forces

What makes the problem difficult? What are the trade-offs? These are constraints that can be changed at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.

Sketch (optional)

visual illustration

Solutions

Verified resolutions and possible resolutions to the problem.

Resulting Context

What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.

Rationale (optional)

Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.

Known Instances (optional)

Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.

May mention:

• A particular business

• Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".

Status (optional until merging)

General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.

You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."

Author(s) (optional)

Often, this is yourself. If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To). Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution).

Acknowledgments (optional)

Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.

Alias (optional)

If this pattern is also known under a different name than what is listed unter Title, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.

Tipos de contribuições

Forneça informações sobre que tipos de contribuições o seu projeto está procurando aqui. Por exemplo, isso pode incluir relatórios de bugs, ajuda para responder perguntas de usuários, melhorias na documentação, correções de bugs e implementações de novas funcionalidades.

Relatórios de Bugs

Adicione informações sobre como enviar relatórios de bugs aqui. Isso deve incluir dicas sobre que tipo de informações o projeto precisará para reproduzir e corrigir problemas. Também pode incluir informações sobre configurações incorretas comuns que parecem ser bugs.

Inclua também informações sobre o que os colaboradores podem esperar em termos de tempo para a primeira resposta e o processo após isso.

Solicitações de features

Adicione informações sobre como enviar solicitações de features aqui. Inclua também informações sobre o que os colaboradores podem esperar em termos de tempo para a primeira resposta e o processo após isso.

Contribuição de Documentação

Inclua informações sobre as melhores práticas de documentação que o seu projeto segue, bem como como criar documentação, verificações a serem executadas e como enviar as alterações feitas de volta para o projeto.

Contribuição de Código Fonte

Esta seção deve conter informações sobre

• Como acessar o código fonte do projeto;

• Layout geral do projeto;

• Quaisquer requisitos para o ambiente de desenvolvimento;

• Diretrizes de formatação de código;

• Como executar o conjunto de testes.

Como se tornar um Colaborador Confiável

Esta seção deve deixar explícito o processo para se tornar um Colaborador Confiável, caso essa opção esteja aberta para os contribuidores.

Como indicar Trusted Committers

Esta seção serve como um lembrete para os Trusted Committers existentes e uma explicação para os novos, detalhando como adicionar outras pessoas à equipe anfitriã. Idealmente, essa informação é idêntica para todos os projetos na organização, para que informações centrais possam ser vinculadas a partir daqui.

Title

Requisitos Comuns

Patlet

O código comum em um repositório compartilhado não está atendendo às necessidades de todas as equipes de projeto que desejam usá-lo; isso é resolvido por meio do alinhamento de requisitos e refatoração.

Problema

O código comum no repositório compartilhado não está atendendo às necessidades de todos os projetos que desejam usá-lo.

Contexto

• Muitos projetos estão tentando usar um código comum. Existe um repositório compartilhado que todos os projetos acessam.

• Alguém (ou algum projeto) escreveu o código em primeiro lugar e o contribuiu para o repositório.

• O código comum é uma pequena porcentagem do resultado geral de qualquer um dos projetos.

• Cada projeto tem seu próprio cronograma de entrega, conjunto de entregas e clientes.

• Este padrão se aplica em qualquer uma dessas situações:

  • há um Proprietário de Código Forte ou seja, todas as mudanças no repositório compartilhado devem ser aprovadas pelo proprietário do repositório

  • há uma propriedade de código fraca ou seja, ninguém realmente é dono do código

  • não há um Patrocinador Benevolente ou seja, nenhuma organização ou executivo está fornecendo recursos para organizar o código comum de forma InnerSource.

Forças

No código disponibilizado pelo projeto original tem um conjunto de necessidades. Suas necessidades são semelhantes ao que algumas das organizações receptoras desejam, mas não exatamente as mesmas. Os requisitos do código devem ser derivados das necessidades reais dos clientes.

As necessidades dos diferentes clientes são geralmente bastante similares; no entanto, elas podem ser expressas de maneira diferente ou ponderadas de forma diferente entre os clientes. Um exemplo pode ser como alguns clientes querem que algum resultado seja apresentado de uma forma, enquanto outros querem que seja apresentado na ordem inversa. É simples fazer a tradução entre eles, mas requer codificação adicional para um dos casos e, como resultado, o módulo que calcula o resultado não pode ser reutilizado por ambos os clientes.

Muitos clientes querem que o fornecedor os ajude a saber do que precisam. A empresa tem muitos "Engenheiros de Sistemas" que escrevem requisitos para os produtos. Esses requisitos devem ser uma destilação das necessidades dos clientes para orientar o desenvolvimento do produto. Reutilizar o código é um objetivo importante para economizar tempo e dinheiro da empresa.

Solução

Existem dois aspectos para resolver este problema que devem ser feitos em paralelo:

1. Alinhar os requisitos dos projetos para que o código que atenda aos requisitos de um projeto também atenda às necessidades dos outros projetos.

2. Refatorar o código em peças menores para as quais os muitos projetos que o utilizam possam concordar com os requisitos.

Além disso, aproveite que os clientes esperam que o fornecedor ajude a elucidar os requisitos. Promova o alinhamento dos requisitos durante as negociações com o cliente e influencie os requisitos do cliente em vez de alterar o componente.

No exemplo apresentado acima, o fornecedor ajuda ambos os clientes a perceberem que eles querem a mesma coisa, e isso economizará esforço (e dinheiro) se eles concordarem em aceitar o resultado no mesmo formato.

Contexto Resultante

Isso pode exigir negociação de mudanças nos requisitos com o cliente. As mudanças também podem exigir o envolvimento das equipes de vendas e gerentes de produtos para obter alinhamento nos requisitos. O cliente pode precisar de incentivos, como descontos, para concordar com as mudanças.

Um desafio relacionado (e possivelmente um novo padrão) é um exercício de escrita de histórias circulares relatado em uma empresa que usa o InnerSource. Em resumo:

• Os desenvolvedores escrevem uma história para resolver um problema de uma maneira.

• Os gerentes de programa reescrevem a história para expressar melhor suas necessidades - mantendo a essência da história. Quando a história retorna para os desenvolvedores, eles não a reconhecem como algo que eles queriam fazer originalmente e, portanto, hesitam em implementá-la.

• A solução para esse padrão é ter mais assentos ao redor da mesa de planejamento para que as modificações de histórias sejam compreendidas em todo o projeto, não apenas nos campos dos desenvolvedores ou gerentes de programa.

Instâncias Conhecidas

• Grande provedor de telecomunicações

Estado

• Structured

Autores

Robert Hanmer

Reconhecimento

• Manrique Lopez

• Daniel Izquierdo

• Tim Yao

• Sebastian Spier

Histórico de Tradução

• 2023-04-20 - Tradução Eneri Junior

• 2023-04-20 - Tradução Humberto Zilio

Title

Repositório Pontuação de Atividade

Patlet

Potenciais contribuidores desejam encontrar projetos InnerSource ativos que precisem de sua ajuda. Ao calcular uma pontuação de atividade do repositório para cada projeto, uma lista classificada de projetos pode ser criada (por exemplo, no Portal InnerSource), para que os potenciais contribuidores possam determinar mais facilmente em qual projeto desejam contribuir.

Problema

Em que ordem os projetos InnerSource devem ser apresentados? Indicadores de classificação típicos, como GitHub Stars, Número de Forks, Número de Commits, Linhas de Código, Última Atualização, não são suficientes para indicar de forma concisa a atividade de um projeto.

Projetos ativos com muita tração, mas também projetos relativamente novos e entusiasmados que precisam de novos contribuidores, devem ser classificados acima de projetos maduros com pouca atividade ou em modo de manutenção.

Uma nova métrica derivada de vários indicadores de desempenho é necessária para definir uma pontuação confiável e versátil para o nível de atividade de um projeto. Ela pode ser usada para ordenar projetos de acordo com o nível de atividade deles.

História

Quando o InnerSource é praticado por um longo período de tempo ou se expande além de um certo número de projetos (digamos 50 para ter um limite significativo), torna-se difícil encontrar os projetos InnerSource mais populares e ativos no momento. Projetos que existem por muito tempo são conhecidos, mas podem não estar tão ativos. Projetos relativamente novos, por outro lado, não têm reputação ou uma comunidade ativa ainda.

Uma lista de projetos InnerSource não deve ser considerada um recurso estático, mas sim um local emocionante para descobrir e explorar projetos novos e ativos, assim como uma página de notícias que lista os tópicos mais interessantes do dia primeiro. Portanto, é benéfico quando a ordem dos projetos é atualizada regularmente e muda de acordo com a popularidade e atividade do projeto.

Essas considerações levaram a um primeiro protótipo para calcular uma pontuação de atividade do repositório, que funcionou surpreendentemente bem e determina uma ordem sempre em mudança de projetos de acordo com a sua atividade.

Contexto

A descoberta de projetos InnerSource pode ser facilitada com o Portal InnerSource e o padrão Gig Marketplace, ou promovendo projetos em outros canais de comunicação e plataformas. A pontuação de atividade define uma ordem padrão na qual os projetos são apresentados à comunidade.

Forças

Indicadores-chave de desempenho automatizados que podem ser obtidos consultando a API do GitHub são apenas parte da verdade. E quanto à qualidade do código, a disponibilidade de boa documentação ou uma comunidade ativa e prestativa que torna o projeto um local divertido para contribuir?

Esses KPIs "soft" teriam que ser adicionados manualmente ou de forma semi-automática ao cálculo e à pontuação resultante. Se existirem ferramentas que forneçam mais contexto para o repositório, como relatórios de cobertura de código, eles podem ser facilmente incorporados.

Esboço

Abordagem centralizada para calcular e aplicar a pontuação de atividade do repositório. Para mais detalhes, veja Contexto Resultante.

Solução

A pontuação de atividade do repositório é um valor numérico que representa a atividade (no GitHub) de um projeto InnerSource. Ela é derivada automaticamente de estatísticas do repositório, como estrelas (GitHub stars), observadores (watches) e forks, e pode ser enriquecida com KPIs de outras ferramentas ou avaliações manuais.

Além disso, considera parâmetros de atividade como a data da última atualização e a data de criação do repositório para impulsionar projetos jovens com muita tração. Projetos com diretrizes de contribuição, estatísticas de participação ativa e problemas (backlog público) recebem uma classificação mais alta também.

Tudo isso pode ser obtido e calculado automaticamente usando o conjunto de resultados da API de pesquisa do GitHub e API de estatísticas do GitHub. Outros sistemas de controle de versão de código, como BitBucket, GitLab e Gerrit, podem ser integrados também, se uma API similar estiver disponível.

O código abaixo pressupõe que a variável repo contenha uma entidade obtida a partir da API de pesquisa do GitHub (search) e que o objeto participation contenha uma entidade da API do GitHub (stats/participation).

Ajustes manuais de acordo com os KPIs "soft" (consulte Forças) podem ser feitos conforme necessário.

// calcular uma pontuação virtual de InnerSource a partir de estrelas, seguidores, commits e issues
function calculateScore(repo) {
    // a pontuação inicial é 50 para dar a repositórios ativos com baixos KPIs do GitHub (forks, seguidores, estrelas) um ponto de partida melhor
    let iScore = 50;
    // ponderação: forks e seguidores contam mais, depois estrelas, adiciona um pouco de pontuação para issues abertas também
    iScore += repo.forks_count * 5;
    iScore += (repo.subscribers_count ? repo.subscribers_count : 0);
    iScore += repo.stargazers_count / 3;
    iScore += repo.open_issues_count / 5;

    // atualizado nos últimos 3 meses: adiciona um bônus multiplicador entre 0..1 à pontuação geral (1 = atualizado hoje, 0 = atualizado há mais de 100 dias)
    let iDaysSinceLastUpdate = (new Date().getTime() - new Date(repo.updated_at).getTime()) / 1000 / 86400;
    iScore = iScore * ((1 + (100 - Math.min(iDaysSinceLastUpdate, 100))) / 100);

    // avaliar estatísticas de participação nos últimos 3 meses
    repo._InnerSourceMetadata = repo._InnerSourceMetadata || {};
    if (repo._InnerSourceMetadata.participation) {
        // média de commits: adiciona um bônus multiplicador entre 0..1 à pontuação geral (1 = >10 commits por semana, 0 = menos de 3 commits por semana)
        let iAverageCommitsPerWeek = repo._InnerSourceMetadata.participation.slice(-13).reduce((a, b) => a + b) / 13;
        iScore = iScore * ((1 + (Math.min(Math.max(iAverageCommitsPerWeek - 3, 0), 7))) / 7);
    }

    // cálculo do boost:
    // todos os repositórios atualizados no ano anterior receberão um boost de até 1000 diminuindo com os dias desde a última atualização
    let iBoost = (1000 - Math.min(iDaysSinceLastUpdate, 365) * 2.74);
    // dimensionar gradualmente o boost de acordo com a data de criação do repositório para misturar com estatísticas de engajamento "reais"
    let iDaysSinceCreation = (new Date().getTime() - new Date(repo.created_at).getTime()) / 1000 / 86400;
    iBoost *= (365 - Math.min(iDaysSinceCreation, 365)) / 365;
    // adicionar boost à pontuação
    iScore += iBoost;
    // dar aos projetos com uma descrição significativa um boost estático de 50
    iScore += (repo.description?.length > 30 || repo._InnerSourceMetadata.motivation?.length > 30 ? 50 : 0);
    // dar aos projetos com um arquivo de diretrizes de contribuição (CONTRIBUTING.md) um boost estático de 100
    iScore += (repo._InnerSourceMetadata.guidelines ? 100 : 0);
    // construir uma escala logarítmica para projetos muito ativos (aberta, mas estabilizando em torno de 5000)
    if (iScore > 3000) {
        iScore = 3000 + Math.log(iScore) * 100;
    }
    // a pontuação final é um valor arredondado começando de 0 (subtraindo o valor inicial)
    iScore = Math.round(iScore - 50);
    // adicionar pontuação aos metadados instantaneamente
    repo._InnerSourceMetadata.score = iScore;

    return iScore;
}

Contexto Resultante

Os contribuidores têm a liberdade de dedicar parte do seu tempo a projetos InnerSource. Eles podem optar por contribuir para um projeto do qual dependem para o trabalho em sua equipe regular. No entanto, também podem escolher contribuir para algo completamente diferente, com base em seus interesses e objetivos de desenvolvimento pessoal.

Os projetos podem ser ordenados e apresentados de acordo com a pontuação de atividade do repositório, proporcionando uma ordem significativa em um portal que apresenta projetos a potenciais novos contribuidores. A pontuação pode ser calculada instantaneamente ou em um trabalho de fundo que avalia todos os projetos regularmente e armazena uma lista de resultados.

Um rastreador que pesquisa regularmente todos os repositórios InnerSource (por exemplo, marcados com um tópico específico no GitHub) também pode ser uma adição útil. Ele fornece uma lista classificada de projetos que podem ser usados como entrada para ferramentas como o InnerSource Portal, um mecanismo de busca ou um bot de chat interativo.

Justificativa

A pontuação de atividade do repositório é um cálculo simples baseado na API do GitHub. Pode ser totalmente automatizada e facilmente adaptada a novos requisitos.

Instâncias Conhecidas

• Usado no portal de projetos InnerSource da SAP para definir a ordem padrão dos projetos InnerSource. Foi criado pela primeira vez em julho de 2020 e vem sendo ajustado e atualizado com frequência desde então. Quando proposto para o InnerSourceCommons em julho de 2020, este padrão emergiu. Veja também Michael Graf & Harish B (SAP) em ISC.S11 - O Caminho Inesperado da Aplicação de Padrões InnerSource.

Estado

• Structured

Autores

Michael Graf (SAP)

Reconhecimento

Um agradecimento à comunidade InnerSource Commons por fornecer conselhos extremamente rápidos e muitas contribuições úteis para enriquecer este padrão! Em especial:

• Johannes Tigges

• Sebastian Spier

• Maximilian Capraro

• Tim Yao

Histórico de Tradução

• 2023-08-20 - Tradução Eneri Junior

• 2023-08-20 - Tradução Humberto Zilio

Title

Tomada de Decisão Transparente entre Equipes usando RFCs

Patlet

Projetos InnerSource que desejam alcançar altas taxas de participação e tomar as melhores decisões possíveis para todos os envolvidos precisam encontrar maneiras de criar sistemas participativos ao longo de todo o ciclo de vida do software. A publicação de documentos internos de "Requests for Comments" (RFCs) permite discussões desde o início do processo de design e aumenta as chances de construir soluções com um alto grau de comprometimento de todas as partes envolvidas.

Problema

Para que um projeto InnerSource seja saudável, ele precisa de um número substancial de contribuidores. Esses contribuidores (ou equipes) podem ter diferentes requisitos para o projeto em questão, por exemplo, eles podem querer adicionar recursos ao projeto que não são compatíveis entre si ou que levem a um excesso de complexidade na arquitetura.

Descobrir tais desacordos ou mal-entendidos tardiamente no processo, por exemplo, após o software já ter sido construído, é muito custoso. Esses desacordos podem levar à frustração de todas as partes envolvidas e até mesmo serem prejudiciais para a cultura de colaboração saudável do projeto. Uma situação comum em que tal desacordo surge é uma solicitação de alteração (pull request) que fica aberta por muito tempo, pois o autor da solicitação e os mantenedores do projeto basicamente não concordam que a alteração proposta deva ser feita.

Para um projeto InnerSource, essa situação ocorre com mais frequência quando o projeto é mantido por várias equipes na empresa, ou seja, possui propriedade compartilhada.

História

Um projeto ou aplicação composta por vários projetos é mantido por várias equipes diferentes, cada uma delas sendo responsável por diferentes áreas do projeto ou aplicação. Essas equipes fazem contribuições InnerSource nas áreas umas das outras, mas mudanças maiores que afetam várias partes do projeto são apenas conduzidas pelos líderes técnicos das equipes trabalhando juntos, ou nem acontecem. Isso resulta na maioria dos engenheiros não sendo capazes de realizar mudanças em larga escala que cortem várias partes do projeto, o que reduz a inovação e as oportunidades de colaboração.

Ao implementar um processo e um modelo para RFCs (Requests for Comments), as equipes e indivíduos são capacitados a propor mudanças significativas que afetem várias partes do projeto através de um processo de tomada de decisão transparente, com consulta entre as equipes feita de forma assíncrona. Isso resulta em maior inovação, colaboração mais próxima e disseminação de conhecimento. Isso depende do comprometimento de todas as disciplinas em todos os níveis e de um ambiente de segurança psicológica para que as pessoas possam propor e debater ideias abertamente.

Assim como em qualquer processo, isso deve ser continuamente aprimorado. Pode ser necessário fazer alterações no modelo ou no processo de RFC para garantir que seja inclusivo, colaborativo e eficaz.

Contexto

• Compartilhamento de Propriedade por Muitas Equipes de um Projeto InnerSource

• Decisões de design abrangentes não podem ser sempre tomadas por um órgão central (por exemplo, um grupo de arquitetos), pois eles não têm tempo suficiente nem conhecimento específico do domínio para tomar boas decisões em todos os casos.

• Vários tipos de usuários têm entrada sobre a direção que um determinado projeto está tomando. Esses usuários podem ser: Desenvolvedores, Proprietários de Produto, Gerentes de Produto, etc.

• As decisões precisam ser tomadas de forma assíncrona, pelo menos em parte, já que não é viável realizar reuniões síncronas frequentes com todos os participantes.

• Existe o desejo de documentar as decisões tomadas, ou seja, garantir que sejam registradas por escrito, em vez de apenas verbalmente.

Forças

• Na maioria das vezes, as partes envolvidas desejam tomar uma decisão bastante rápida (por exemplo, o tempo de design inicial é bastante limitado).

• Escrever as coisas (sem implementá-las imediatamente) muitas vezes é uma nova habilidade para muitas das pessoas envolvidas.

Esboço

Solução

Elementos importantes da solução são:

• uma descrição de quando publicar um RFC (e quando não fazê-lo)

• um modelo para documentos RFC

  • deve provocar o autor do RFC a considerar sua proposta a partir de várias perspectivas

  • deve fornecer uma visão geral acessível de alto nível e uma explicação detalhada em profundidade

• um processo bem conhecido e leve em torno de RFCs, por exemplo,

  • como publicar um RFC e compartilhá-lo com todas as partes interessadas (por exemplo, Slack, lista de discussão)

  • como coletar feedback para o RFC

  • como trabalhar no feedback recebido

  • como levar o RFC a uma conclusão ou decisão (por exemplo, mantenedores relevantes nomeados para aprovar)

  • ferramentas adequadas escolhidas (por exemplo, não-engenheiros podem não ter acesso a ferramentas de controle de código fonte)

• um compromisso em iterar no modelo de RFC e no processo

Exemplos/Modelos

Contexto Resultante

Implementar um processo semelhante a um RFC provou ser valioso, pois torna o processo de tomada de decisão entre equipes mais transparente para todos, permitindo que todas as vozes sejam ouvidas.

Efeitos positivos observáveis:

• democratização do processo de tomada de decisão para decisões que impactam muitas equipes (aliviando também os líderes das equipes dessa carga)

• um método de comunicação assíncrono e aberto que funciona bem entre várias equipes e localidades

• empodera indivíduos e equipes a efetuar mudanças em grande escala

• registro de decisões tomadas para que as pessoas possam consultar para obter contexto

• amplia o impacto dos engenheiros experientes pois eles podem contribuir com soluções de forma assíncrona e remota, em vez de precisar estar presente em uma reunião

• alinhamento de terminologia, por exemplo, ao esclarecer nossa terminologia de testes, como "o que é um teste de sistema?"

• alinhamento de processos, por exemplo, ao esclarecer o processo de suporte fora do horário comercial

• maior clareza de pensamento, já que escrever um RFC faz com que o autor se desafie mais do que normalmente faria

A abordagem de RFC também possui riscos que queremos destacar:

• Nem sempre funciona! Por exemplo, algumas pessoas ainda podem discordar de uma decisão que já foi tomada por meio de um RFC. No entanto, ter o processo de tomada de decisão por escrito ainda é benéfico nesses cenários, pois você pode direcionar as pessoas para quando e por que uma determinada decisão foi tomada.

• Um RFC pode se tornar extenso e difícil de gerenciar. Isso muitas vezes é evidenciado por longas conversas e discussões a seu respeito. Nessas situações, podemos decidir complementar o RFC com comunicação síncrona, como um grupo de trabalho e reuniões presenciais. Mas o tempo ainda é economizado, pois as pessoas podem ler o RFC antes da reunião em vez de terem todas as informações compartilhadas durante a reunião.

Justificativa

Instâncias Conhecidas

Estado

Structured

Autores

• Tom Sadler

• Sebastian Spier

Aliases

• Architecture Decision Record (ADRs) - Não necessariamente um equivalente direto, pois às vezes eles podem ser usados de maneira diferente, por exemplo, RFCs para buscar opiniões e construir consenso, ADRs para registrar decisões e detalhes de implementação.

Histórico de Tradução

Title

Trusted Committer

Patlet

Muitos projetos InnerSource se encontram em uma situação em que consistentemente recebem feedback, funcionalidades e correções de bugs de contribuidores. Nessas situações, os mantenedores do projeto buscam maneiras de reconhecer e recompensar o trabalho do contribuidor acima e além de contribuições individuais.

Problema

• Os mantenedores do projeto desejam encontrar maneiras de aumentar a capacidade de suporte a um projeto.

• Os mantenedores do projeto desejam encontrar maneiras de prolongar o valor entregue por um projeto.

• Os mantenedores do projeto desejam recompensar visivelmente os contribuidores frequentes e capacitá-los a ampliar sua contribuição de valor.

• Falta de mecanismo e linguagem para reconhecer contribuições entre equipes dentro de uma organização.

Contexto

• Você é o mantenedor de uma biblioteca, serviço ou recurso compartilhado entre equipes.

• Você recebe contribuições regulares.

• Você recebe solicitações regulares de novos recursos.

• Você recebe solicitações regulares de correções de bugs.

• Existem contribuidores motivados buscando construir experiência por meio de projetos InnerSource.

Forças

• Ao longo do ciclo de vida de um projeto, o foco dos mantenedores pode se deslocar para acomodar as mudanças nas prioridades comerciais.

• Os contribuidores buscam reconhecimento visível de suas contribuições, demonstrando valor.

• Manter um projeto de complexidade razoável é desgastante para uma equipe pequena.

• Desenvolver recursos do projeto em escala é desgastante para uma equipe pequena.

Solução

Definindo o Papel de Trusted Committer para um Projeto

O que um Trusted Committer lida depende de cada projeto e de seus mantenedores. Certifique-se de documentar dentro do projeto o escopo do seu papel de Trusted Committer. A documentação clara estabelece as expectativas para novos membros da comunidade e estabelece o papel para futuros candidatos.

As seguintes são algumas diretrizes para identificar um possível Trusted Committer:

• Um participante ativo nos canais da comunidade (Slack, triagem de problemas no JIRA, etc.) se torna um Trusted Committer, formalizando assim seu papel no suporte à comunidade.

• Alguém que frequentemente submete código, documentação ou outras mudanças no repositório. Comece incluindo essa pessoa em pull requests. Se eles estão participando ativamente de pull requests, considere abordá-los sobre oportunidades de colaboração adicional no projeto.

Formalizando Trusted Committers

O primeiro passo é abordar os candidatos para se tornarem Trusted Committers. Os mantenedores devem educar os candidatos sobre o papel de um Trusted Committer. Não há expectativa de que os candidatos aceitem o papel de Trusted Committer. Cada candidato deve avaliar se tem a disponibilidade necessária para assumir as responsabilidades.

Quando um candidato aceita o papel, cabe aos mantenedores do projeto reconhecer publicamente a transição de usuário para Trusted Committer. Também é uma boa ideia adicionar o nome deles a uma seção de Trusted Committers no README do seu projeto. Como exemplo:

Mantendo Relacionamentos com Trusted Committers

Depois de formalizar um novo Trusted Committer, é uma boa ideia mantê-los informados à medida que você continua a iterar no projeto. Manter eles informados pode ser tão simples quanto convidá-los para o canal do projeto ou tão envolvente quanto incluí-los em suas sessões de planejamento. Mais oportunidades de envolvimento oferecem aos Trusted Committers um caminho para se tornarem Mantenedores, se assim desejarem.

Encerrando a Participação de um Trusted Committer

Existem momentos que podem exigir a remoção de um Trusted Committer, como quando o Trusted Committer:

• Não está mais disposto a participar;

• Não consegue mais desempenhar suas funções;

• Não está mais empregado pela empresa.

Um plano para remover o acesso aos recursos do projeto deve ser acordado por ambas as partes, incluindo a transição de sua entrada na seção de Trusted Committers do projeto para uma lista de contribuidores passados.

Contexto Resultante

Para os Contribuidores

Alcançar o status de Trusted Committer para um projeto demonstra iniciativa em contribuir para o projeto da comunidade. O reconhecimento por esses esforços pode ser usado durante as revisões anuais com os gerentes.

Para os Mantenedores

Conforme um projeto amadurece, os mantenedores podem ficar menos familiarizados com aspectos-chave de um projeto. Trusted Committers preenchem essas lacunas, garantindo que todos os aspectos do projeto sejam melhor atendidos ao longo do tempo.

Um conjunto saudável de Trusted Committers garante que, se os mantenedores do projeto se afastarem, haja um plano para a administração responsável.

Instâncias Conhecidas

Isso foi experimentado e comprovado como bem-sucedido em:

• Nike

• PayPal

• Mercado Libre - adiciona uma seção no arquivo CONTRIBUTING.md para informar quem são os Trusted Committers.

• Robert Bosch GmbH - nós não chamamos o papel de 'Trusted Committer', mas tivemos esse papel no início de nossa jornada InnerSource. Os Trusted Committers eram financiados em 100% do tempo para poderem se concentrar nesse papel.

Estado

• Structured

• Published internally at Nike; drafted via pull-request in June of 2018.

Autores

Reconhecimento

Histórico de Tradução

Missão

Esta seção deve conter uma breve descrição (3-5 frases) da missão do seu projeto. O objetivo é declarar sobre o que você planeja trabalhar e ajudar os contribuidores externos a entenderem mais ou menos quais tipos de recursos provavelmente serão bem-vindos para este projeto.

Veja também o em Producing Open Source Software.

Primeiros Passos

Esta seção deve conter uma breve documentação escrita para usuários iniciantes sobre como começar a usar o projeto. Além disso, documentação mais detalhada pode ser vinculada a partir daqui.

Mais Informações

Esta seção pode listar qualquer uma ou todas as seguintes informações:

• Uma lista de recursos, casos de uso que o software aborda.

• Informações sobre os princípios de design que são usados para resolver compensações.

• Links para documentação de nível de usuário mais detalhada.

• Respostas às perguntas frequentes (FAQ), de preferência em um formato que permita vincular a perguntas específicas e suas respostas para referência mais fácil.

Obtendo Ajuda

Esta seção deve conter uma breve documentação sobre como obter ajuda para o projeto como usuário. Isso pode ser tão simples quanto direcionar os usuários para o rastreador de problemas se este for o método que seu projeto deseja usar para responder a perguntas. Também pode apontar para um canal de chat arquivado e pesquisável, alguma lista de discussão arquivada e pesquisável, ou algum fórum online para usuários.

Se envolvendo

Esta seção deve incluir informações sobre como entrar em contato com o projeto: Tipicamente, isso conterá links para canais de comunicação arquivados, pesquisáveis e linkáveis.

Quem somos

Este é um bom lugar para dar crédito aos Trusted Committers do projeto.

Também é um bom lugar para incluir informações sobre o que significa ser um Trusted Committer para este projeto - embora o ideal seja que todos os projetos em uma organização usem a mesma definição que é vinculada apenas a partir daqui. A razão para manter o link aqui é para que colegas que não têm ou têm pouca experiência em trabalhar e contribuir para projetos InnerSource tenham um link direto de volta para informações em toda a empresa dos projetos tecnológicos necessários para seu trabalho diário.

Contribuindo

Esta seção deve documentar (ou vincular à documentação) tudo o que um contribuidor de primeira viagem precisa saber para começar. Normalmente, nem todos os tópicos abaixo serão cobertos. Foque no que difere em seu projeto do setup padrão e no que contribuidores anteriores acharam difícil de entender.

• Encontrar o código-fonte.

• Encontrar uma lista de problemas para os quais seu projeto precisa de ajuda - esses problemas podem ser técnicos e não técnicos. Geralmente você manterá esses problemas em um rastreador de problemas acessível aos contribuidores.

• Links para documentação adicional, por exemplo, sobre a arquitetura do projeto, convenções gerais de codificação, convenções de teste...

• Para contribuições técnicas: Fazer alterações, construir o projeto e testar suas alterações.

• Enviar suas alterações de volta para o projeto.

Idealmente, você também inclui informações sobre como é o processo preferido para alterações no projeto: Os contribuidores devem primeiro abrir um problema e enviar uma proposta, ou eles podem enviar alterações imediatamente? O que é importante para você ao revisar as contribuições?

Além disso, você deve esboçar quaisquer valores de design que deseja seguir no projeto. Tornar esses valores explícitos frequentemente ajuda a resolver trade-offs mais rapidamente e mais facilmente. Além disso, ajuda a tornar transparentes as alterações em pressupostos anteriormente implícitos.

Com o tempo, você notará que esta seção crescerá substancialmente. Nesse caso, considere mover as informações para arquivos separados, como CONTRIBUTING.md e TESTING.md.

Title

Licença InnerSource

Patlet

Duas entidades jurídicas que pertencem à mesma organização desejam compartilhar código-fonte de software entre si, mas estão preocupadas com as implicações em termos de responsabilidades legais ou contabilidade entre empresas.

Uma Licença InnerSource fornece uma estrutura legal reutilizável para o compartilhamento de código-fonte dentro da organização. Isso abre novas opções de colaboração e torna explícitos os direitos e obrigações das entidades jurídicas envolvidas.

Problema

Quando duas ou mais entidades jurídicas dentro de uma organização desejam compartilhar código entre si, elas precisam de um acordo sobre os termos e, muitas vezes, um contrato legal. Criar tais acordos por projeto requer esforço e cria uma barreira para o compartilhamento. Por exemplo, uma equipe dentro de uma entidade jurídica pode decidir não compartilhar seu código-fonte com outra entidade jurídica na organização porque parece complicado.

Barreiras para o compartilhamento podem levar a silos e à duplicação de esforços na reconstrução de soluções semelhantes em várias partes da organização.

No momento do compartilhamento do código-fonte, não é possível prever de forma confiável qual será o valor do compartilhamento. Se a atividade de compartilhamento requer um esforço significativo (ou seja, negociar os termos de uso), as entidades jurídicas têm menos probabilidade de fazê-lo, pois estão preocupadas com o retorno sobre o investimento.

Contexto

• Uma grande organização com muitas entidades jurídicas (subsidiárias) que desejam compartilhar código. À medida que a organização cresce, o valor desse padrão aumenta.

• Conforme definição, as entidades jurídicas possuem seus próprios direitos e obrigações legais.

• Várias dessas entidades jurídicas estão desenvolvendo software e usando serviços de outras entidades jurídicas. Elas têm motivação para contribuir com o código-fonte umas das outras.

• Uma complexidade suficiente da organização e de sua estrutura organizacional.

Forças

• Nível de esforço necessário para escrever acordos formais, especialmente se eles precisam levar em conta perspectivas técnicas, legais e de negócios.

• Uma grande organização (composta por muitas entidades jurídicas) possui muitas regulações internas. Quaisquer novos acordos que sejam feitos devem estar em conformidade com essas regulamentações, como segurança, privacidade, processos de aquisição, etc. O volume de regulamentações pode dificultar a avaliação de se o compartilhamento de software entre duas entidades jurídicas está em conformidade com essas regulamentações, especialmente quando não há um procedimento padrão.

• Se alguma das entidades jurídicas na organização possui um modelo de negócios que depende de código proprietário e contabilidade de taxas de licenciamento dentro da organização.

• Cultura empresarial que não está acostumada à colaboração InnerSource e ao compartilhamento de código. Isso resulta em incerteza sobre os direitos e obrigações ao usar código compartilhado.

• A liberdade de uso do software leva à competição e à disseminação da propriedade.

• Existem contratos legais em vigor que cobrem o compartilhamento de código-fonte. Esses contratos não são padronizados, o que cria esforço adicional na negociação e compreensão para cada projeto. Os contratos existentes também podem não permitir o compartilhamento de código-fonte de uma maneira aberta o suficiente para suportar uma abordagem verdadeiramente InnerSource.

• Alternativamente, não existem contratos legais em vigor, mas o código-fonte é compartilhado informalmente. Isso pode criar incerteza em casos em que é necessária clareza sobre a propriedade e os direitos e obrigações.

Solução

Criar uma Licença InnerSource personalizada de acordo com as necessidades da organização em questão (e suas entidades jurídicas). Esta licença precisa ser genérica o suficiente para ser aplicada às relações interempresariais mais importantes.

É importante escrever a Licença InnerSource de forma que permita verdadeiras colaborações semelhantes ao OpenSource entre as fronteiras das entidades jurídicas envolvidas. Portanto, as 4 liberdades do software livre devem ser integradas à licença.

A Licença é escrita como um documento legal formal e pode ser usada como parte de contratos entre as entidades jurídicas para governar acordos de compartilhamento de código.

Contexto Resultante

Com a Licença InnerSource, temos uma ferramenta para compartilhar código entre entidades jurídicas dentro da nossa organização.

A licença simplifica as conversas dentro da nossa organização sobre compartilhamento de código-fonte e está motivando as primeiras entidades jurídicas a fazê-lo.

Nota: O experimento descrito em Instâncias Conhecidas ainda está em uma fase inicial. Portanto, um contexto resultante sólido ainda não foi formado. Em alguns meses, os efeitos da Licença InnerSource nesse espaço de problemas estarão mais claros e esta seção poderá ser atualizada.

Instâncias Conhecidas

A DB Systel criou sua própria Licença InnerSource, consulte DB Inner Source License. Eles usaram a EUPL, já que ela oferecia um ponto de partida semelhante ao do código aberto, e depois trabalharam nas restrições e regras adicionais necessárias em seu contexto organizacional específico.

As primeiras entidades legais (empresas) dentro da DB AG estão usando sua Licença InnerSource.

Uma consequência positiva que já está aparecendo é que simplifica a conversa, especialmente se algumas das partes envolvidas ainda não conhecem bem o conceito de InnerSource. Licenças são um conceito bem conhecido, portanto ter uma licença InnerSource é um ótimo ponto de partida para discussão.

Os experimentos também estão revelando que existem outros desafios de colaboração que precisam ser resolvidos para levar a um verdadeiro modelo de contribuição e colaboração InnerSource.

Os desafios de colaboração mencionados incluem:

• tornar os projetos licenciados como InnerSource descobríveis.

• construir comunidades para colaboração em projetos, assim como em Open Source.

Vale mencionar que até agora, o software compartilhado sob essa licença InnerSource é principalmente ferramentas, infraestrutura e ferramentas mais baixas na pilha de tecnologia.

Estado

• Structured

• O experimento listado em Exemplos Conhecidos está em execução desde 02/2020. A experiência inicial mostra os primeiros efeitos positivos, mas mais experiência é necessária para avaliar totalmente o padrão.

Autores

• Cornelius Schumacher (DB Systel GmbH)

• Schlomo Schapiro (DB Systel GmbH)

• Sebastian Spier

Referências

• FOSSBack 2020 Presentation: Cornelius Schumacher - Blending Open Source and Corporate Values - watch 27:30 and onwards for details about the InnerSource License

• DB Inner Source License

Glossário

• organização - um guarda-chuva para várias entidades legais. (sinônimos: grupo, empresa) (e.g., Lufthansa) -entidade jurídica - Uma entidade que possui seus próprios direitos e obrigações legais (sinônimos: empresa, subsidiária) (por exemplo, Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...)

Histórico de Tradução

• 2023-05-04 - Tradução Eneri Junior

• 2023-05-04 - Tradução Humberto Zilio