Como funciona o InnerSource?

Digamos que a equipe A use um software produzido pela equipe B. A equipe A envia uma solicitação de recurso para a equipe B, mas a equipe B não consegue implementar esse recurso a tempo para a equipe A. Em uma configuração InnerSource, se a equipe A não conseguir obter essa solicitação de recurso, ela enviará um pull request. Isso quer dizer que a equipe A implementa o recurso diretamente no software da equipe B e envia um pull request com as alterações de código. Integrantes da Equipe B para revisar e aceitar o código enviado.

Neste exemplo, chamamos a equipe A de equipe Guest e a equipe B de equipe Host. Os termos Guest e Host sugerem uma situação análoga a receber um visitante em casa. Nessa situação, a maioria das pessoas quer ser um bom anfitrião. Eles garantem que as coisas sejam mantidas limpas e arrumadas antes da chegada de seus convidados. Os visitantes são recebidos na porta e convidados a entrar. Eles podem usar os recursos e utilidades que estão nas áreas públicas da casa. Pode haver algumas regras da casa que os hóspedes devem seguir. Da mesma forma, a maioria dos hóspedes deseja mostrar respeito pela casa e pelo anfitrião. Eles são cuidadosos com os itens da casa e seguem as regras durante a estadia. Eles podem esperar ou aguardar um convite de retorno, desde que tenham sido corteses e educados. Esses conceitos em torno de uma visita domiciliar são uma metáfora para a atitude e os comportamentos que as equipes devem trazer enquanto uma hospeda a outra, fazendo uma contribuição de convidado para a base de código.

Vamos dar uma olhada mais de perto em como a mecânica do processo InnerSource pode funcionar. Para ajudar nesta explicação, nomearemos alguns indivíduos-chave nas equipes de convidados e anfitriões. Primeiro, o Product Owner determina qual funcionalidade a equipe anfitriã está disposta a aceitar como contribuição. O Contributor é o indivíduo da equipe convidada que envia a contribuição do código para revisão pela equipe anfitriã. O Trusted Committer representa a equipe anfitriã no fornecimento de qualquer suporte e orientação oportunos que o Contributor precisa para enviar com sucesso o pull request. Em pequenos esforços, uma única pessoa geralmente preenche os papéis de Product Owner e de Trusted Committer.

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

Observe que essas etapas não pressupõem um sistema específico para a organização geral do tempo ou das prioridades de uma equipe. A InnerSource assume que as equipes já possuem métodos de organização existentes e fornece uma estrutura de como usá-los para trabalhar em conjunto onde há uma equipe convidada desejando contribuir com código para um host.

Essa opção funciona bem para a equipe convidada porque ela obtém a funcionalidade de que precisa quando precisa, sem assumir a carga de longo prazo da manutenção da solução. Funciona para a equipe anfitriã porque ela consegue escalar e atender melhor seus consumidores. Funciona para a empresa como um todo porque as 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 os problemas da empresa, em vez da mecânica da negociação de recursos e do processo de escalonamento.