Join us on Tuesday, 30th April, at 3pm BST / 4pm CEST / 9am CDT / 7am PDT to hear Florence Rolland, from Novo Nordisk, and Laura Jeffords Greenberg, from Worksome, discuss

Mastering Open Source: Balancing the Code Supply Chain, IP, and Legal Considerations

Quais problemas o InnerSource resolve?

A InnerSource incentiva e recompensa a colaboração e a reutilização de código com qualquer pessoa, independentemente de sua posição na estrutura organizacional da empresa. Essa abordagem difere do que é visto em 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 na mesma empresa entregando softwares separados com o software de uma equipe dependendo do software da outra. Um exemplo pode ser uma experiência do usuário que depende de um serviço de API para recuperar dados para exibição. Essa situação é comum em grandes empresas, onde uma única equipe de produção de software pode ter dezenas ou centenas de consumidores.

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

  1. Espere. A equipe de consumo pode não fazer nada e continuar sem a funcionalidade solicitada. Esta opção requer a menor quantidade de trabalho do seu lado. Dependendo do benefício da solicitação de recurso, esperar pode ser bom. No entanto, pode vir com muita dor, especialmente se a funcionalidade solicitada nunca for entregue.

  2. Gambiarra. Uma equipe consumidora que não quer esperar pode fazer trabalho extra em outro lugar para compensar a ausência do recurso solicitado. Este trabalho extra pode vir como mudança no projeto alvo. Alternativamente, eles podem criar um novo projeto que atenda às suas necessidades e substitua o uso de todo ou parte do sistema da equipe de produção (duplicação de código/projeto). Essa estratégia permite que a equipe consumidora obtenha o recurso solicitado apenas por meio de seus próprios esforços. Ele vem com várias desvantagens, no entanto.

    1. Qualquer trabalho feito pela equipe de consumo permanece indisponível para qualquer outro consumidor com a mesma solicitação de recurso.

    2. A equipe de consumo inadvertidamente se inscreveu para o fardo de longo prazo de manter o código recém-escrito, que não está no domínio de competência da equipe principal.

    3. A empresa como um todo adquire projetos e códigos duplicados no mesmo espaço de problema.

  3. Escalar. A equipe de consumo pode não aceitar um "não" como resposta e, em vez disso, advogar para alguém na hierarquia de gerenciamento dos produtores para influenciar (ou forçar) a equipe de produção a fazer o trabalho. Essa opção parece atraente para a equipe consumidora porque eles obtêm o recurso solicitado sem fazer o trabalho de implementá-lo ou mantê-lo. No entanto, ainda é um empecilho para a equipe, porque necessariamente desvia um pouco de sua atenção e trabalho para a tarefa de escalonamento que não é de engenharia. Além disso, essa opção não é dimensionável, pois há apenas algumas vezes em que um consumidor pode escalar solicitações de recursos antes de prejudicar sua credibilidade. A escalação é igualmente perturbadora (ainda mais) para os membros da equipe de produção, que são retirados de seu fluxo de trabalho normal e métodos de priorização para lidar com a solicitação de recurso escalada.

Esta discussão prepara o terreno para o InnerSource. O InnerSource se aplica ao mesmo tipo de situação em que uma equipe de consumo não consegue obter o que precisa por meio de solicitação de recurso. O InnerSource fornece uma maneira para as equipes obterem os benefícios de esperar, solução alternativa e escalar sem as desvantagens associadas.

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

Contributors