FAQ

Depende! Um projeto InnerSource que incentiva pequenos pull requests e tem diretrizes de contribuição claras pode exigir pouca sobrecarga, com a maior parte do trabalho sendo revisões de código. Para saber mais sobre as práticas que podem reduzir a necessidade de manutenção de projetos InnerSource, sugerimos que você consulte InnerSource Patterns, especialmente:

50% mais esforço para o commit. 100% menos esforço para manter.

Por favor, faça-o se o projeto fizer sentido! Alguns projetos são específicos para sua empresa ou são uma vantagem competitiva, então você vai querer mantê-los como InnerSource. Alguns precisam iterar mais rapidamente do que pode ser feito abertamente.

Se a sua organização não estiver familiarizada com a execução de projetos de código aberto, a InnerSource pode ajudar as pessoas a aprender as habilidades necessárias para abrir o código no futuro.

Depende de quão longe você está indo. Você provavelmente irá muito mais longe do que pensa.

Nesse caso, sua equipe principal está com falta de pessoal. Uma equipe saudável é composta de forma que haja tempo para ajudar os colaboradores e fazer contribuições essenciais.

Você pode mitigar isso definindo a expectativa, possivelmente por meio de SLAs. Se os contribuidores esperam revisões de PR em uma hora, talvez você fique parado revisando PRs o tempo todo, mas se você definir um SLA de 1 dia ou 1 semana, esse não será o caso.

Descubra o que eles querem e obtenha um exemplo de trabalho do InnerSource, de preferência dentro da sua organização, que mostre que eles estão conseguindo. Se o OSPO/ISPO da sua organização gerencia projetos InnerSource, entre em contato com eles para obter suporte.

A InnerSource oferece aos engenheiros a oportunidade de desenvolver sua carreira, tanto em termos de habilidades quanto reconhecimento dentro de sua organização:

Além disso, muitos engenheiros valorizam o código aberto; O InnerSource adota práticas de código aberto e pode ser um passo em direção ao código aberto para muitos projetos.

Trabalhar juntos! Isso pode ser completamente assíncrono por meio de pull requests ou envolver atualizações regulares da comunidade - o que funcionar para você.

A comunicação e o apoio devem ir em ambas as direções e ser abertos e colaborativos, promovendo uma cultura de segurança psicológica. O feedback sobre contribuições ou código existente deve ser abordado com uma mentalidade de crescimento e como parceria para melhorar as coisas.

Por meio das funções Trusted Committer e Product Owner, você ainda pode garantir que o código recebido seja adequado tanto do ponto de vista do produto quanto da engenharia. Você não precisa mesclar o código que não é adequado.

Você também deve definir diretrizes de contribuição claras e ser transparente na direção do projeto. Alguns Padrões que podem ajudar:

Sua equipe e a cultura da organização em geral devem valorizar a colaboração. Concentre-se no valor comercial - as equipes são capazes de se desbloquear onde o software que usam tem bugs ou não possui os recursos necessários. Onde os colaboradores não têm necessidade imediata de negócios, você pode anunciar que está procurando ajuda.