Introdução

Confira a Introdução para aprender sobre os tipos de problemas onde InnerSource pode ajudar, como fazê-lo, os tipos de benefícios que você pode esperar ver participando, e os princípios subjacentes que fazem tudo funcionar.

Introdução

Este Caminho de Aprendizagem dá uma introdução ao InnerSource. InnerSource é a aplicação de práticas e princípios de código aberto ao desenvolvimento de software dentro da empresa. O software InnerSource continua proprietário da empresa, mas dentro dela está aberto para qualquer um usá-lo e contribuir para ele. Esta estratégia permite uma ampla e eficaz colaboração, produzindo software que é ágil e ágil às necessidades em mudança de seus muitos stakeholders internos.

Este caminho de aprendizagem ensina como reconhecer situações que são bons candidatos para InnerSource. Descreveremos em alto nível como InnerSource pode ajudar nessas situações. Você vai se familiarizar com termos compartilhados usados quando discutir InnerSource. Também enumeraremos os princípios-chave sobre os quais InnerSource se baseia e os benefícios vistos quando é aplicado efetivamente.

Que problemas InnerSource resolve?

InnerSource incentiva e recompensa colaboração e reutilização de código com qualquer um, independentemente de sua posição na estrutura organizacional de uma empresa. Essa abordagem difere do que é visto nas organizações tradicionais onde ideias e produtos de trabalho tendem a ficar presos dentro dos limites da hierarquia corporativa interna e seus silos. Vamos explorar uma situação que dê um exemplo dessa ideia.

Imagine duas equipes da mesma empresa entregando peças separadas de software com o software de uma equipe dependendo do outro. Um exemplo pode ser uma experiência de usuário que depende de um serviço de API para recuperar dados para exibição. Esta situação é comum em uma grande empresa onde uma única equipe produzindo software pode ter dezenas ou centenas de consumidores.

Quando as equipes de consumo precisam de muitos recursos, equipes de produção normalmente têm algum tipo de requisitos e processo de priorização para decidir quais recursos irão trabalhar. Para pedidos de recursos críticos que não são priorizados para o trabalho imediato, a equipe consumidora geralmente pode escolher uma das três opções, cada uma das quais vem com suas próprias desvantagens.

1. Espere.. A equipe de consumo pode não fazer nada e mancar sem a funcionalidade solicitada. Essa opção requer o mínimo de trabalho do lado deles. Dependendo do benefício do pedido, esperar pode ser ótimo. No entanto, pode vir com dor real, especialmente se a funcionalidade solicitada nunca for entregue.
2. Abortar. Uma equipe consumidora que não quer esperar pode fazer trabalho extra em outro lugar para compensar a ausência de seu recurso solicitado. Este trabalho extra pode vir como mudança no projeto consumidor. Alternativamente, eles podem criar um novo projeto que atenda às suas necessidades e substitua seu uso de tudo ou parte do sistema da equipe de produção (duplicação de código/projeto). Esta estratégia permite que a equipe consumidora obtenha o recurso solicitado apenas através de seus próprios esforços. Mas vem com várias desvantagens.
   1. Qualquer trabalho feito pela equipe consumidora permanece indisponível para qualquer outro consumidor com o mesmo pedido de recurso.
   2. A equipe consumidora inadvertidamente se inscreveu para o ônus de longo prazo de manter o código recém-escrito, que não está no domínio de sua competência principal.
   3. A empresa adquire projetos duplicados e códigos no mesmo espaço de problemas.
3. Escalada. A equipe consumidora pode não aceitar “não” como resposta e, em vez disso, defender alguém na hierarquia de gestão dos produtores para influenciar (ou forçar) a equipe produtora para fazer o trabalho. Esta opção parece atraente para a equipe consumidora porque eles recebem o recurso solicitado sem fazer o trabalho para implementá-lo ou mantê-lo. Mas ainda é um problema para a equipe, porque isso necessariamente desvia a atenção deles e trabalha para a tarefa de não engenharia de escalada. Além disso, esta opção não escala como há apenas tantas vezes que um consumidor pode aumentar os pedidos de recursos antes de prejudicar sua credibilidade. A escalada é igualmente perturbadora (ainda mais) para os membros da equipe produtora, que são retirados de seu fluxo de trabalho normal e métodos de priorização para lidar com o pedido de recursos aumentado.

Esta discussão prepara o palco para InnerSource. InnerSource se aplica ao mesmo tipo de situação em que uma equipe consumidora é incapaz de obter o que precisa por solicitação de recursos. InnerSource fornece uma maneira para as equipes ganharem os benefícios deEspere., workaround, eSubirSem as desvantagens associadas.

InnerSource também fornece uma melhoria geral para a cultura de engenharia como engenheiros têm a chance de trabalhar com uma maior variedade de novas tecnologias e pessoas. Os desenvolvedores são mentores e aprendem uns com os outros enquanto compartilham ideias e soluções entre silos organizacionais. Engenheiros e equipes podem reutilizar soluções internas para problemas de mercadoria, permitindo que se concentrem em fluxos de trabalho de maior valor para a organização.

Como funciona o InnerSource?

Digamos que a equipe A usa software produzido pela equipe B. A equipe A apresenta um pedido de recurso para a equipe B, mas a equipe B não é capaz de implementar esse recurso a tempo para a equipe A. Em uma configuração InnerSource, se a equipe A não pode receber este pedido de recurso, então ele envia um pedido de pull em vez disso. Ou seja, a equipe A implementa o recurso diretamente no software da equipe B e submete um pedido com as mudanças de código. Equipe B parceiros para rever e aceitar o código submetido.

Neste exemplo, chamamos a equipe A deConvidadoequipe e equipe B oHost.Equipe. Os termosConvidadoeHost.sugere uma situação análoga a receber uma visita em casa. Nessa situação, a maioria das pessoas quer ser uma boa anfitriã. Eles asseguram que as coisas sejam mantidas limpas e arrumadas na antecipação da chegada de seus convidados. Visitantes são recebidos na porta e convidados a entrar. Eles podem usar as características e utilidades que estão nas áreas públicas da casa. Pode haver algumas regras que os hóspedes devem seguir. Da mesma forma, a maioria dos convidados quer mostrar respeito pela casa e seu anfitrião. Eles são cuidadosos com os itens na casa e seguem as regras durante a estadia. Podem esperar ou esperar um convite de volta desde que tenham sido cortês e educados. Estes conceitos em torno de uma visita domiciliar são uma metáfora para a atitude e comportamentos que as equipes devem trazer como um anfitrião outro fazendo uma contribuição convidada para a base de códigos.

Vamos olhar mais de perto como a mecânica do processo InnerSource pode funcionar. Para ajudar nesta explicação, vamos nomear alguns indivíduos chave nas equipes de convidados e hospedeiros. Primeiro, o responsável pelo produto determina que funcionalidade a equipe anfitriã está disposta a aceitar como uma contribuição. O Contribuidor é o indivíduo da equipe convidada que submete a contribuição de código para revisão pela equipe anfitriã. O Trusted Committer representa a equipe anfitriã em fornecer qualquer apoio oportuno e orientação que o contribuinte precisa para apresentar com sucesso o pedido de retirada. Em pequenos, os esforços de uma única pessoa muitas vezes preenchem Os dois. O dono do produto e papéis confiáveis.

Com essas definições, aqui está o esboço básico de uma contribuição InnerSource.

• Equipe convidada ou contribuinte solicita uma característica da equipe anfitriã.
• O dono do produto garante que histórias de usuários representando o pedido de recursos sejam criadas, seja por membros da equipe convidada ou equipe anfitriã. Estas histórias devem descrever o recurso solicitado em termos agradáveis para a equipe convidada. Eles também listam detalhes da equipe anfitriã sobre como o recurso deve ser entregue para que o trabalho seja aceito. Exemplos de tais detalhes incluem restrições de arquitetura, convenções de codificação, usos de dependência, contratos de dados, etc.
• Suportado pelo responsável, o contribuinte submete o pedido de retirada para implementar o recurso solicitado.

Note que esses passos não assumem um sistema específico para a organização geral do tempo ou prioridades de uma equipe. InnerSource assume que as equipes já têm métodos de organização existentes e fornece uma estrutura de como usá-los para trabalhar juntos onde há uma equipe convidada desejando contribuir código para um anfitrião.

Esta opção funciona bem para a equipe de convidados porque eles têm a funcionalidade que eles precisam quando eles precisam dele sem assumir o fardo de longo prazo de manutenção da solução. Funciona para a equipe anfitriã porque eles são capazes de escalar melhor e servir seus consumidores. Funciona para a empresa em geral porque soluções para problemas compartilhados acabam em locais compartilhados e mantidos centralmente onde qualquer um pode usá-los. Mais tempo de engenharia permanece focado na produção de código que resolve problemas da empresa em vez da mecânica do processo de negociação e escalada.

• A equipe anfitriã pode ser representada peloEquipe CorePadrão.
• OTrusted CommitterPadrão.

Quais são os benefícios do InnerSource?

Há muitos benefícios em colaborar via InnerSource. InnerSource dá a uma empresa uma estratégia escalável paraEquipes convidadas para receber pedidos de recursos quando precisarem.Sem o fardo de manutenção a longo prazo. A empresa como um todo ganha como o tempo das equipes convidadas é colocado em código que outros podem usar.

Embora esse resultado seja um benefício brilhante do InnerSource, há muitos benefícios para os anfitriões que recebem contribuições regulares do InnerSource. Lembre-se que, como parte do processo InnerSource, o dono do produto na equipe anfitriã concorda desde o início que recursos contribuídos são bons e desejáveis. InnerSource permite que a equipe anfitriã recebaAjuda na criação de um produto melhor.Para seus consumidores!

InnerSource fornece à equipe anfitriã uma estratégia escalávelpor satisfazer diferentes quantidades de recursos solicitados de seus muitos consumidores. Dada a capacidade fixa dos membros em tempo integral da equipe anfitriã, é provável que, às vezes, os roteiros de negócios combinados de seus consumidores exigirão muito (ou mesmo desrazoavelmente) grandes quantidades de trabalho a ser feito nos produtos da equipe anfitriã. Sem InnerSource, esta situação facilmente leva a uma equipe estressada e sobrecarregada lidando com muitos pedidos de recursos escalados para seus líderes.

No entanto, se a equipe anfitriã operar via InnerSource, os recursos de engenharia necessários para construir essas características aparecerão em proporção à sua importância na forma de colaboradores convidados.InnerSource se torna um multiplicador de forçaque permite que a equipe hospedeira aja temporariamente maior do que seu tamanho real durante tempos de alta demanda. Quando a demanda acabar, a equipe retornará aos níveis normais, tudo sem microgestão de itens de trabalho. InnerSource permite que o tempo de engenharia flua organicamente onde a organização precisa em um determinado momento.

Além do trabalho bruto que a equipe anfitriã é capaz de realizar em seu sistema, contribuições regulares InnerSource dar a equipe anfitriãmelhores requisitos e alinhamento de priorização com todos os seus consumidores.. Uma equipe anfitriã pode fazer suas melhores exigências se reunindo sobre o trabalho que produz, mas quando o próprio consumidor é quem submete o trabalho as chances são muito maiores que a mudança resultante está alinhada com o que o consumidor precisa. Embora possa ser apenas uma equipe convidada submetendo a mudança, essa equipe é provavelmente representativa de muitos outros consumidores.

Além deste alinhamento, há também uma formação geral e educação de contribuidores como eles trabalham e aprendem com Commissores confiáveis.. Esta interação ajuda os contribuintes a aprender e crescer em sua carreira, resultando em maior satisfação no trabalho.. A documentação do projeto melhora para permitir essas contribuições em escala. Contribuintes sentem uma participação no projeto da equipe anfitriã. É algo que eles recomendam para seus colegas ou novas equipes que eles se juntem. Eles entendem melhor o projeto e são capazes de responder perguntas sobre isso para outros, aliviando a equipe anfitriã de alguns desses fardos. Mais pessoas contribuindo para um projeto, naturalmente, cruzando ideias de toda a empresa. Este aprendizado e alinhamento entre equipes ao longo do tempo serve para quebrar os silos tradicionais da empresa.

Princípios InnerSource

Cada empresa, equipe, projeto e indivíduo é diferente. Por causa desse fato, a forma exata como o conceito de InnerSource funciona vai variar de uma situação para outra. No seu núcleo, no entanto, estão quatro princípios que formam a base de qualquer instância bem sucedida de InnerSource. Estes princípios têm inspiração em projetos de código aberto bem sucedidos e são necessários para InnerSource alcançar os benefícios descritos anteriormente.

Os princípios são:

• Abertura
• Transparência
• Mentoria Priorizada
• Contribuição do código voluntário

Vamos dar uma olhada em cada um desses princípios em mais detalhes.

A configuração de um projeto aberto permite contribuir sem fricção. Projetos devem ser descobertos e bem documentados através de arquivos README.MD e CONTRIBUTING.MD dentro da raiz do acordo. Qualquer um dentro de uma organização deve ser capaz de encontrar um projeto desejado e subir sem uma quantidade excessiva de orientação direta dos membros da equipe anfitriã. Informações de contato da equipe de acolhimento devem ser prevalentes com tantos canais quanto faz sentido para o projeto. A intenção da equipe de acolhimento de aceitar contribuições InnerSource para seu projeto deve ser compartilhada através de canais de organização relevantes para aumentar a conscientização. Especialmente em ambientes menores, você pode querer estabelecer uma transmissão regular no trabalho InnerSource que sua equipe está fazendo. Em ambientes maiores, no entanto, tal transmissão pode criar muito ruído, e pode ser mais apropriado para garantir que o projeto seja detectável em uma ferramenta fácil de usar. Lembre-se, o objetivo é a consciência usar os canais apropriados que trabalham na sua empresa.

De modo algum é uma lista exaustiva. A abertura do projeto normalmente será diretamente relacionada ao sucesso do projeto em termos de InnerSource. Quanto mais aberto, menos barreiras serão criadas para possíveis contribuintes. Quanto menos aberto, mais difícil se torna para alguém contribuir.

Para que as equipes convidadas possam contribuir significativamente para um projeto, a equipe anfitriã deve sertransparente. Isso significa que as equipes de convidados devem ser capazes de entender:

• O projeto/repo e sua direção
• Exigências de destaque
• Progresso nos requisitos de recursos.
• Tomada de decisão da equipe anfitriã

Quando possível, o acima deve ser comunicado de forma clara e detalhada, das definições internas das equipes de itens para cenários especiais específicos para o projeto. Essa comunicação deve ser feita de uma forma que possa ser facilmente consultada e compreendida para aqueles que não fazem parte da equipe anfitriã.

Mentorship De equipe anfitriã para equipe convidada via Commissores confiáveis. é um aspecto chave do InnerSource. Colaboradores em equipes convidadas são mais elevadas para que eles entendam o suficiente sobre o projeto/repo da equipe anfitriã para mudá-lo com sucesso. No processo de fazer isso, eles vêm a entender melhor o sistema de software da equipe anfitriã como um consumidor geral e embaixador para o projeto/software. Este contribuinte individual pode, ao longo do tempo e com experiência, assumir um papel mais amplo no projeto como um comprometedor confiável.

É crítico que esta orientação para contribuidores sejaPriorizadopela equipe anfitriã. A equipe de acolhimento deve se esforçar para ter tempo para orientar colaboradores convidados.no momento em que o contribuinte precisaao contrário de quando é conveniente para a equipe anfitriã. Às vezes, pode ser uma mudança cultural para os engenheiros da equipe anfitriã passarem tempo ajudando os outros a codificar em vez de apenas codificar a si mesmos. Essa orientação é valiosa tanto para o contribuinte individual quanto para o anfitrião, e vale a pena fazer bem. Prova ser mutuamente benéfico a longo prazo. Ao melhorar o código, o contribuinte forja ou melhora os relacionamentos dentro de uma organização que pode não ter existido de outra forma. O código aberto reconhece este ponto e considera uma honra alcançar o status de comitente confiável em um projeto.

A primeira palavraVoluntário.significa que o engajamento em InnerSource das equipes convidadas e anfitriãs ocorre de livre vontade. A equipe convidada doa o código voluntariamente para a equipe anfitriã e a equipe anfitriã aceita voluntariamente. Esta natureza opt-in significa que cada equipe precisa ter certeza de que seu envolvimento agrega valor aos objetivos dos outros. Nunca é necessária uma equipe anfitriã para aceitar uma contribuição que não esteja em alinhamento final com sua missão geral. Nunca é necessária uma equipe convidada para apresentar uma contribuição que não promova sua própria missão e prioridades.

A palavraCódigoenfatiza que a colaboração entre convidado e anfitrião vai até o código. O envolvimento dos convidados em questões de abertura, atualização de requisitos, correção de documentos, etc. é bom, mas a colaboração precisa chegar ao ponto de enviar código para alcançar todos os benefícios que discutimos.

Conclusão

Neste caminho de aprendizagem, fizemos uma introdução ao InnerSource. InnerSource aplica boas práticas e princípios de código aberto ao desenvolvimento interno de software. Ele dá uma opção adicional aos consumidores quando as equipes produtoras não são capazes de fazer um pedido de recursos necessários. InnerSource envolve um proprietário do produto e Commissor de confiança Da Equipe anfitriã. bem como um contribuidor Da Equipe convidada. Feito efetivamente, InnerSource traz muitos benefícios para ambas as equipes participantes. Os princípios-chave sobre os quais o InnerSource eficaz funciona são Contribuição de código voluntária e mentora priorizada.

Enquanto este treinamento contém uma visão geral de alto nível de InnerSource, há muitos mais detalhes úteis em fazer InnerSource realmente trabalhar para sua equipe. Se você quiser ficar conectado com a conversa em andamento sobre InnerSource e suas melhores práticas, então junte-seInnerSource Commons. Os Commons patrocinam um canal Slack, um grupo de trabalho InnerSource padrões, e várias cimeiras presenciais a cada ano. Participação nos Commons é uma ótima maneira de ficar conectado com o mais recente em InnerSource.

InnerSource é certo para o meu projeto?

InnerSource é a aplicação de princípios de código aberto ao desenvolvimento de software interno da empresa. Feito certo, ele desbloqueia o progresso e facilita a adoção de serviços compartilhados e módulos. Este artigo contém orientações e perguntas para se perguntar quando considerar a adoção de uma abordagem InnerSource para executar seu projeto.

Uma abordagem InnerSource só faz sentido se as contribuições são esperadas dos usuários do projeto. Você pode esperar contribuições para vir se você ver ou antecipar quantidades visíveis de energia direcionada para sua área de projeto por seus usuários. Alguns exemplos:

• Altas quantidades de uso do projeto e adoção.
• Mais pedidos do que sua equipe tem tempo para preencher.
• Usuários fazendo soluções para compensar a falta de recursos em seu projeto.
• Pedidos de recursos que levam quase tanto tempo para explicar como eles só para implementar.
• Várias dependências do seu projeto.

Mesmo com contribuintes dispostos, o código não flui apenas. Você precisará encorajar e apoiar contribuições através de atividades como:

• Entender os cenários dos usuários e sugerir quais contribuições em seu projeto poderiam ajudá-los a atender esses cenários.
• Convidando os usuários a fazerem as contribuições que precisam e acompanhando-os para garantir que eles as façam.
• Mantendo umCONTRIBUIÇÃO.Documento que contém tudo que um engenheiro precisa saber para contribuir para o projeto.
• Dando orientação e direção para implementar uma dada contribuição.
• Estar disponível durante horas regulares para qualquer pergunta ad hoc que os contribuintes tenham.
• Revisão oportuna dos pedidos de retirada.
• Manutenção contínua do código apresentado.Janela de garantia).

Projetos InnerSource fazem sentido quando o projeto é específico para a empresa ou quando seu uso exclusivo dá à empresa uma vantagem estratégica de negócios. Outros projetos colaborativos devem ser executados como código aberto para aumentar a contribuição e o impacto.

Se as contribuições vieremeVocê vai apoiar essas contribuições.eSeu projeto é específico da empresa, então InnerSource é certo para o seu projeto.

A Mentalidade InnerSource

InnerSource ajuda quando há várias equipes em nossa empresa que têm uma necessidade compartilhada – negócios ou técnicos. Queremos um projeto compartilhado que todos possam alavancar. Este compartilhamento permite que cada equipe passe o máximo de tempo possível em sua única área de negócios em vez de reinventar o que alguém fez antes.

Gerenciamos projetos compartilhados via InnerSource, o que significa que aplicamos práticas e princípios de código aberto à maneira como eles são executados. Estes projetos estão abertos para reutilização e contribuição em toda a empresa. Em teoria, qualquer projeto pode ser um projeto InnerSource, mas você pode encontrar projetos populares InnerSource listados no portal InnerSource.

InnerSource precisa fazer parte do nosso trabalho. Ao entregar em seu roteiro de software, quando você se deparar com uma necessidade que é provavelmente compartilhada com outras equipes, pare e pense. Mais alguém na empresa já construiu algo que (quase) resolve essa necessidade? Se assim for, a bordo desse projeto, mesmo que isso signifique contribuir para ele primeiro para estendê-lo para atender ao seu caso de uso. Se não há um projeto existente, então construa-o de uma forma sharable consigo mesmo como seu primeiro consumidor, e então listá-lo no portal InnerSource.

Trabalhar assim nos ajuda a tirar o máximo proveito do tempo de engenharia que todos colocamos e nos permite passar mais tempo em nossa missão única como empresa. Adote a Mentalidade InnerSource.

Diário de trabalho

Mais de uma resposta pode estar correta em algumas perguntas.

1. Sua equipe não tem recursos para criar seu software principal.
2. Você está importunando um gerente de alto nível para conseguir outra equipe para implementar uma mudança de software
3. A maioria do seu software é comprado em vez de construído.
4. Poucas mudanças de software estão sendo submetidas à sua equipe.

InnerSource permite que outras equipes atualizem seu software para satisfazer suas necessidades. Você não pode depender de outras equipes para assumir suas próprias prioridades, nem pode atribuir um projeto a outra equipe. InnerSource depende de contribuições voluntárias, e trabalha onde os interesses do convidado e da equipe anfitriã se alinham.

Grandes organizações que atribuem equipes diferentes a diferentes partes de uma base de códigos rotineiramente sofrem batalhas por prioridades. O que é crítico para o plano de negócios da sua equipe pode ser visto como um incômodo estranho para a equipe anfitriã que possui o código. Com InnerSource, você adiciona o código que você precisa diretamente ao projeto da outra equipe, embora você seja responsável por seguir as diretrizes deles e a equipe anfitriã vete-o antes de entrar.

Se um terceiro entregar uma solução proprietária, você não pode participar do desenvolvimento. No entanto, software livre e de código aberto de terceiros oferece excelentes oportunidades de colaboração. As habilidades que você aprende fazendo InnerSource podem ser aplicadas a projetos de código aberto fora de sua empresa, e vice-versa.

InnerSource explora os desejos de outras equipes para melhorar seu software. Se seu software é maduro e não precisa de muitas mudanças, não há razão para você ou outras equipes melhorarem. Suas habilidades podem ser direcionadas para novos projetos.

1. Impede que várias equipes tenham que implementar diferentes soluções para problemas compartilhados.
2. Traz gestores de alto nível para ajudar as equipes a decidirem prioridades.
3. Requer menos desenvolvedores para criar a mesma quantidade de código.
4. Isso restringe a manutenção a pessoas que conhecem bem a base de códigos.

Quando cada equipe é responsável por uma única base de código, equipes diferentes tendem a adicionar código às suas bases de código para implementar o mesmo recurso. Isso não só é desperdício, mas pode levar a incompatibilidades. Com InnerSource, as equipes colaboram em adicionar código a uma única base de código para implementar o recurso.

InnerSource permite que os membros da equipe definam suas prioridades. É um sistema voluntário que apresenta participação popular. Na verdade, no seu melhor, reduz o envolvimento de gerentes de alto nível, permitindo-lhes colocar seus esforços para outras necessidades estratégicas da organização.

InnerSource não é mágica. A mesma quantidade de trabalho é necessária para escrever mil linhas de código como antes. As pessoas se envolvem em InnerSource para ter certeza de obter o código que seus projetos precisam, e investir o tempo necessário para escrevê-lo.

A ideia do InnerSource é se espalhar pela manutenção, bem como por novas características. Qualquer um na empresa que veja um problema tem poder para consertar. As equipes usam InnerSource porque vêem a participação generalizada como uma força.

Mais de uma resposta pode estar correta em algumas perguntas.

1. Usuário final
2. Contribuidor
3. Compromissor confiável.
4. Dono do produto

InnerSource é uma atividade técnica na qual desenvolvedores (contribuidores e commissores confiáveis) participam, apoiados por proprietários de produtos. Embora atender às necessidades dos usuários finais seja o objetivo final, os usuários finais não determinam quem faz o trabalho ou como é feito, e, portanto, não fazem parte das comunicações e atividades que constituem InnerSource.

Por que 2, 3 e 4 estão corretos: os três papéis chave em InnerSource são o contribuinte que cria as contribuições básicas (código, documentação e diretrizes), o comiter confiável que orienta contribuidores, e o dono do produto que representa as necessidades da organização.

1. Treinamento rigoroso para garantir que todos os engenheiros conheçam toda a base de código da empresa.
2. Fazendo donos de produtos examinarem cada mudança.
3. Revisão de código por commissores de confiança
4. Resenhas de especialistas fora da empresa

Não é razoável pensar que todo engenheiro pode entender todo o código da empresa. Cada engenheiro precisa entender apenas o código que tem um impacto imediato em seu trabalho. No entanto, InnerSource permite aos engenheiros explorar o código de outras equipes para a profundidade que eles querem, e contribuir para o código de outra equipe enquanto têm uma compreensão limitada dele. O engenheiro pode simplesmente ler uma função e fornecer uma correção de erros, por exemplo.

Por que o 2 está incorreto, os comitentes confiáveis verificam cada mudança. InnerSource coloca a responsabilidade mais próxima dos desenvolvedores, menor na hierarquia organizacional, e liberta os donos de produtos para se concentrarem em estratégia e requisitos.

Por que 3 está correto: são commissores confiáveis escolhidos pela comunidade por sua capacidade demonstrada de escrever código excelente, suas habilidades de comunicação e orientação, e seu conhecimento do código e dos objetivos da equipe. Eles revisam todas as contribuições antes de deixá-los entrar na base de códigos.

InnerSource, ao contrário do código aberto, mantém o código dentro da empresa. Claro, as equipes são livres para trazer especialistas externos (como para avaliações de segurança), mas isso não faz parte do InnerSource.

1. Garantindo que o código corresponda às diretrizes de estilo da equipe.
2. Escrevendo o código como solicitado pelo contribuinte.
3. Mencionando o contribuinte
4. Misturando o código do contribuinte na base de código de sua equipe

Toda equipe de desenvolvimento tem que manter padrões para codificar estilo, estrutura, qualidade, segurança e adesão geral aos objetivos do projeto. Embora estes sejam escritos e compartilhados com contribuidores, o comitente confiável é o ponto chave de transmissão onde a equipe transmite suas diretrizes para estranhos.

O objetivo do InnerSource é capacitar os forasteiros para contribuir com o código de uma equipe, oferecendo a orientação em controle de qualidade, bem como padrões e diretrizes. Isso minaria toda a premissa de InnerSource se um membro da equipe fizesse a escrita solicitada pelo estranho; isso seria simplesmente uma resposta tradicional a um pedido de recurso. Além disso, se o comiter de confiança escreveu o código, InnerSource simplesmente imporia novos encargos de comunicação sem remover nenhum fardo de programação.

O código de um contribuinte é um excelente ponto de partida para treinar o contribuinte. Mentorar pode produzir um crescimento educacional e pessoal que é ainda mais benéfico do que a própria contribuição do código. E contribuidores, mesmo que competentes e conhecedores sobre a base de códigos e os objetivos da equipe, podem se beneficiar de orientação para alinhar suas contribuições com os objetivos e padrões de uma equipe.

O comitente confiável, junto com as responsabilidades educacionais e de mentor, desempenha o papel típico de um comitente em um projeto, garantindo que o código funcione bem e não quebre outra coisa na aplicação.

Mais de uma resposta pode estar correta em algumas perguntas.

1. Melhora o código com contribuições de seus usuários.
2. Isso os liberta de ter que entender as necessidades de seus usuários.
3. Eles recebem menos interrupções durante períodos de atividade de alto volume.
4. Ele destaca sua importância para a organização maior

Por que 1 está correto: as equipes anfitriãs abrem sua base de códigos para os outros e se esforçam para verificar contribuições precisamente porque seu código acaba melhor e com mais recursos do que se eles mesmos fizessem todos os códigos.

InnerSource não tem impacto na definição de requisitos e prioridades. Como em qualquer desenvolvimento de software profissional, os desenvolvedores têm que entender seus usuários.

Por que 3 está incorreto, contribuidores de muitas equipes submetem mudanças ao código, espera-se, durante períodos de atividade de alto volume. Isso significa que a equipe anfitriã tem que fazer muitas interações com estranhos. O resultado, no entanto, é mais código em um curto período de tempo.

Por que 4 está errado, os estrangeiros fazem contribuições para projetos que reconhecem como importantes, a importância precede as doações voluntárias de código. Porque InnerSource solicita contribuições voluntárias, forasteiros trabalham apenas em projetos que consideram importantes. No entanto, uma equipe pode pedir a estranhos para contribuir, persuadindo-os de que o projeto é importante.

1. Gerentes alocam mais dinheiro para a equipe.
2. Pessoas fora da empresa podem ver e comentar em código.
3. Contribuidores podem complementar o trabalho da equipe anfitriã na base de códigos da equipe.
4. Leva a uma ampliação permanente da equipe.

InnerSource não tem efeito no financiamento de uma equipe. É verdade que os gerentes de outras equipes podem alocar dinheiro para que seus próprios membros possam trabalhar em código de prioridade em outras equipes. Eles pagam seus próprios membros para trabalhar em código, não os membros de outras equipes.

InnerSource não é código aberto. O código não é publicado fora da empresa. No entanto, algumas empresas escolhem abrir seu código em algum momento, transformando um projeto InnerSource em um de código aberto.

InnerSource convida a equipe fora da equipe anfitriã para trabalhar no código da equipe anfitriã. A equipe anfitriã se beneficia da compreensão dos estranhos sobre as necessidades de seus usuários ou consumidores, bem como das novas características adicionadas.

O InnerSource pode ser um valioso multiplicador de força durante o tempo, trazendo pessoas de muitas equipes para completar rapidamente o código de alta prioridade. Mas depois da crise, as pessoas voltam a trabalhar em projetos dentro de suas próprias equipes.

1. Estabelecer barreiras claras entre as responsabilidades da equipe.
2. Substituir treinamento tradicional por orientação.
3. Traga as idéias de uma equipe para outra.
4. Estabeleça todos os requisitos antes de qualquer codificação começar.

InnerSource confunde as responsabilidades de cada equipe. Seu objetivo é permitir que pessoas de uma equipe colaborem com outra. Os forasteiros aprendem não só o código da equipe anfitriã, mas seu estilo e padrões. Em InnerSource, a equipe de acolhimento incentiva os forasteiros a assumirem maior responsabilidade pelo seu código.

O treinamento tradicional ainda é importante para habilidades básicas, como aprender linguagens de programação, ferramentas de desenvolvimento e boas técnicas de engenharia de software. No entanto, a orientação pode melhorar esse treinamento, e é uma parte importante do InnerSource.

Em um grande projeto, uma equipe produz serviços consumidos por outras equipes. A equipe que codifica o serviço muitas vezes não entende o propósito final e os requisitos, bem como as equipes que constroem sobre o serviço. InnerSource melhora a comunicação entre as equipes, e permite que a equipe com o maior conhecimento do usuário coloque seu código diretamente na base de código de outra equipe após a checagem pela equipe anfitriã.

Os requisitos não estão relacionados com a decisão de usar InnerSource. Por exemplo, InnerSource permite que desenvolvedores dentro e fora de uma equipe negociem recursos enquanto eles vão. É compatível com uma configuração de exigência rígida (modelo de cachoeira) ou uma configuração de exigência solta (modelo ágil). Mas porque InnerSource tende a transformar o poder e a tomada de decisões em saídas externas da organização, incluindo desenvolvedores individuais, incentiva as pessoas a definir suas próprias necessidades no contexto do projeto, e mudá-las para atender novos aspectos do ambiente.

Mais de uma resposta pode estar correta em algumas perguntas.

1. Servir como modelos
2. Parar sua própria codificação para assumir o papel
3. Aumente seu escrutínio do código contribuído.
4. Código de revisão escrito por sua própria equipe

Por que 1 está correto, comutadores confiáveis são escolhidos por causa de seu desempenho superior em tarefas de codificação e seu compromisso em construir uma comunidade. Portanto, seu comportamento serve de modelo para outros na busca de um código melhor e uma comunidade mais forte. Muitos contribuintes querem se tornar cúmplices de confiança.

Por que 2 está errado, os comitentes confiáveis continuam participando de todas as atividades de sua equipe. O papel confiável intensifica suas contribuições, em vez de substituí-las. Eles também precisam continuar codificando (embora provavelmente não tanto quanto antes) a fim de entender o código de sua equipe o suficiente para ajudar os contribuintes externos e julgar seu trabalho. Finalmente, o papel de committer confiável é temporário para alguns desenvolvedores, e eles planejam voltar à codificação em tempo integral.

Quando uma única equipe desenvolve seu próprio código, membros da equipe tendem a compartilhar uma compreensão tácita do código e seus objetivos. Eles podem não precisar de verificação, ou podem fornecer mínima avaliação. InnerSource traz codificadores externos que precisam de verificações mais cuidadosas de seu código, porque eles virão ao projeto com suas próprias visões e experiências.

Todas as contribuições podem se beneficiar com um segundo par de olhos. Então, os autores de confiança reviram o código de estranhos e de sua própria equipe.

1. Respondendo a submissões de código com feedback construtivo e conselhos.
2. Escrevendo um excelente código.
3. Realizando treinamentos presenciais e apresentações.
4. Programação em dupla.

A educação é muitas vezes mais eficaz e duradoura quando os alunos se concentram em projetos específicos e derivam lições gerais de seus próprios esforços. Poucas experiências de aprendizagem são mais poderosas do que pedir a alguém para escrever código e explicar como pode ser melhorado. Este é um papel chave para o comitente confiável.

Escrever um grande código é uma preparação maravilhosa e pré-requisito para ser um comiter confiável, mas ser mentor é mais do que exemplo. A Mentorship deve tentar ensinar os outros e melhorar sua habilidade de codificar o projeto.

Cada papel de committer confiável é acoplado a um projeto específico e é projetado para ajudar contribuições de código individuais a ter o apoio que precisam para que suas contribuições sejam aceitas na base de códigos. A maioria dos treinamentos e apresentações são projetados com uma grande audiência em mente e por isso têm um tópico mais generalizado. O mentor confiável acontece principalmente em um nível individual.

Enquanto a programação de pares pode ser feita remotamente, não há garantia de que os contribuintes possam coordenar horários específicos com commissores confiáveis. A orientação confiável acontece de forma assíncrona e digital.