InnerSource é uma Mentira - Uma Resposta às Concepções Errôneas Comuns
Quando você pesquisa por “InnerSource” no YouTube, um dos primeiros resultados que provavelmente encontrará é um vídeo alegando que “InnerSource é uma mentira.”
(link: https://youtube.com/shorts/53jEP3mPP3E)
Este ponto de vista representa uma armadilha típica na qual muitas pessoas caem quando aprendem sobre InnerSource pela primeira vez.
Quero usar este vídeo como um estudo de caso para explicar que tipo de conclusões enganosas ele promove. Este é um erro que cometi no passado também, e é uma armadilha na qual muitas pessoas que não exploraram profundamente este campo podem facilmente cair. É por isso que quero examinar isso com autorreflexão e ajudar outros a encontrar o caminho certo desvendando essas armadilhas.
A Primeira Concepção Errônea: “Use React Para Que Outros Possam Contribuir” #
Deixe-me primeiro desempacotar o argumento neste caso. O vídeo sugere usar React para aplicações internas “Use React porque outras pessoas podem contribuir para isso.” Este tipo de raciocínio raramente é ouvido em discussões reais sobre InnerSource.
should you use react HTMX or solid or something for your company’s internal application now a lot of people what you’re going to hear is use react so other people can contribute to this
Este argumento pode ser dissecado em três questões principais:
- Mal-entendido fundamental sobre o que InnerSource realmente significa
- Escolher o domínio errado para aplicação de InnerSource
- Confundir perspectivas individuais versus de equipe
O Que InnerSource Realmente Significa #
InnerSource é sobre praticar princípios de código aberto dentro de uma empresa. Não é apenas sobre “contribuir” ou “receber contribuições.”
A maioria das pessoas que interage com código aberto são simplesmente “usuários.” Alguns são apenas consumidores, outros relatam bugs, e apenas uma pequena fração realmente submete pull requests. InnerSource aplica aprendizados de código aberto internamente para criar organizações que são abertas, amplamente acessíveis, com tomada de decisão transparente, e relacionamentos de equipe construídos na confiança através de propriedade e mentoria. Isso cria uma cultura de transparência e colaboração.
Isso é o que “praticar código aberto internamente” significa - não é apenas sobre “receber pull requests.” Pull requests são meramente um resultado desta cultura, não o objetivo principal.
Um Domínio Menos Otimizado para Aplicação de InnerSource #
A segunda questão é que este argumento se desenrola em um domínio onde InnerSource e código aberto enfrentam desafios particulares.
Se você quer “receber pull requests” ou “ter muitas pessoas usando seu código para melhorar a qualidade,” isso pode ser limitado pela natureza do seu produto. É claro que compartilhar “componentes de alta dependência” ou ferramentas de nível de plataforma criaria mais valor do que aplicações para usuários finais. Embora equipes alinhadas ao fluxo ainda devam adotar práticas de código aberto quando benéfico, as dinâmicas de colaboração diferem significativamente.
Na minha experiência trabalhando com empresas corporativas, usar InnerSource para iniciativas de nível de projeto onde os usuários finais são “não-engenheiros” apresenta desafios únicos. Por quê? Porque, em última análise, esses produtos precisam servir às necessidades de “usuários finais” ou “usuários de negócio” que podem carecer de habilidades de desenvolvimento e canais de comunicação diretos com equipes de desenvolvimento. Isso cria requisitos complexos e individualizados e tempos de comunicação mais longos.
Implementações de InnerSource tendem a funcionar relativamente bem quando aplicadas a bibliotecas compartilhadas, componentes de plataforma, ferramentas de desenvolvimento e código de infraestrutura—áreas onde os “usuários” são principalmente outros desenvolvedores que podem contribuir significativamente e se beneficiar de práticas de desenvolvimento colaborativo.
Embora aplicar práticas de InnerSource a aplicações voltadas ao usuário possa trazer benefícios valiosos como transparência e rastreamento melhorado de problemas (o que por si só já vale a pena).
Perspectiva Individual vs. de Equipe #
A terceira questão diz respeito a se “você” se refere a um indivíduo ou uma equipe.
É importante notar que InnerSource não é necessariamente sobre esperar que alguém contribua para “seu projeto pessoal” dentro de uma empresa. Quando InnerSource é aplicado, pode haver casos onde pessoas contribuem para projetos desenvolvidos durante 20% do tempo, como em grandes empresas de tecnologia, mas essa não é necessariamente a abordagem mainstream.
InnerSource é principalmente introduzido e mantido porque gera ROI através de redução de custos, evitando reinventar a roda, criando sinergias, garantia de qualidade, e removendo sobrecarga de comunicação da tomada de decisão hierárquica. Isso tipicamente envolve bibliotecas internas compartilhadas, componentes proprietários de vantagem competitiva, ou coisas com altas dependências que são nicho dentro da empresa. E esses “benefícios de negócio” tipicamente fluem de volta para “operações de equipe” na maioria dos casos. Em última análise, tudo se trata de ROI para equipes e organizações. Se não pensarmos sobre equipes, alguém vai impedir você de contribuir para projetos. Você precisa justificar seu ROI seja de curto ou longo prazo.
O que é único sobre InnerSource é que é fundamentalmente sobre colaboração equipe-para-equipe. É aqui que a maioria das implementações acaba chegando. Não é necessariamente indivíduos contribuindo aleatoriamente para projetos pessoais convenientes. É tipicamente implementado através de relacionamentos de equipe anfitriã e equipe convidada, onde equipes convidadas acompanham partes mantidas por equipes anfitriãs. A maioria das empresas tem funcionários com papéis e responsabilidades definidos, e a colaboração tende a acontecer dentro dessas estruturas.
Portanto, InnerSource é particularmente eficaz quando relacionamentos entre equipes de plataforma e equipes alinhadas ao fluxo (equipes convidadas e equipes anfitriãs) são estabelecidos. Co-criação ativa entre equipes alinhadas ao fluxo ou indivíduos são mais incertas de ter sucesso naturalmente.
Criticar todo o InnerSource baseado em cenários que são improváveis de funcionar não faz sentido lógico.
A Segunda Concepção Errônea: “Isso Nunca Acontece em Empresas Reais” #
because we want people doing that the reality is that’s not what’s going to happen ever at any company ever inner source
Na verdade, isso está acontecendo. Estudos de caso provam isso. Ponto final.
A Terceira Concepção Errônea: “99,69% dos Projetos InnerSource Vão Falhar” #
99.69% a lie you’re going to build the entire project by yourself when it goes down people are going to look to you
Isso pode estar correto dependendo de como você define “InnerSource.” Como mencionado anteriormente, InnerSource não é sobre “receber contribuições de PR.”
No entanto, há três pontos importantes a considerar:
- InnerSource especialmente se aplica a componentes estratégicos - não é necessário para todos os componentes
- Benefícios se estendem além de contribuições ativas
- Código aberto tem o mesmo problema de “taxa de falha”
InnerSource é uma Estratégia Corporativa #
Quando as pessoas pensam sobre InnerSource, às vezes imaginam ideias radicais como “compartilhar todo código dentro da empresa” ou “todos contribuindo para tudo.” Elas podem imaginar centenas de repositórios compartilhados dentro de uma empresa com todos ativamente trocando contribuições. Como código aberto sendo uma estratégia para empresas, InnerSource também é uma estratégia corporativa com prioridades. Empresas compartilham “o que vale a pena compartilhar” primeiro.
Portanto, o número real de bases de código onde código flui ativamente entre equipes e colaboração vibrante entre equipes ocorre é relativamente pequeno. Isso pode de fato ser percentuais de um dígito. No entanto, mesmo sem colaboração ativa entre equipes, muitos projetos podem se beneficiar de serem abertos e transparentes. Neste sentido de InnerSource, empresas podem frequentemente compartilhar valor em muito mais casos.
Embora InnerSource inclua contribuições individuais, é principalmente focado em colaboração equipe-para-equipe. Portanto, o que é compartilhado através de InnerSource tende a ser relativamente nicho dentro de empresas, ou itens específicos para propósitos como distribuições Linux bifurcadas para necessidades particulares. Ou pode simplesmente ser cultura de desenvolvimento similar ao código aberto, como quando GitHub compartilha código Ruby on Rails entre todos os funcionários.
Quando condicionamos esta discussão de percentual em InnerSource que colabora ativamente e é mantido como requisitos comuns, o percentual pode de fato ser relativamente baixo. No entanto, pequenas colaborações como pull requests de documentação ou pequenas mudanças de configuração (enviando pequenos patches) entre equipes convidadas e equipes de plataforma/anfitriãs acontecem relativamente frequentemente. Quando você inclui essas micro-colaborações e benefícios de transparência que previnem esforços duplicados, esses números aumentam significativamente.
Código Aberto Tem o Mesmo “Problema” #
Por outro lado, se definirmos dessa forma, código aberto também seria uma “mentira.” Porque “99,69% dos projetos de código aberto vão falhar.” A maioria do código publicado como código aberto não recebe contribuições. Mas ninguém diz “código aberto é uma mentira” por causa disso. Pessoas buscam código aberto porque há benefícios além de receber contribuições.
Novamente, “receber contribuições” não é o único valor do InnerSource. E o mesmo vale para o valor do código aberto também
Os Benefícios Reais da Transparência #
Manter código interno aberto em vez de oculto - no GitHub, arquitetos ou engenheiros de soluções na equipe de receita podem ser capazes de examinar código fonte para encontrar informações relevantes, potencialmente encontrando detalhes muito próximos a solicitações de clientes, facilitando conversas de suporte mais suaves, e extraindo informações mais precisas de problemas. Eu moro em Tóquio, e às vezes é mais rápido apenas olhar o código Ruby para verificar a implementação, ou ir aos problemas para verificar o contexto das mudanças, em vez de esperar a equipe de produto baseada em SF acordar para perguntar sobre implementação das mudanças e seu contexto.
Usando o comando git blame, você pode identificar os stakeholders “reais” do código e fazer perguntas sobre o contexto das decisões.
Desnecessário dizer, o mesmo se aplica a outras equipes de desenvolvimento. Ter informações prontamente disponíveis sobre componentes que podem criar dependências claramente reduz sobrecarga de comunicação.
InnerSource é sobre praticar princípios de código aberto internamente. InnerSource não é apenas sobre enviar pull requests de um lado para o outro - é sobre garantir transparência e obter benefícios através de colaboração estilo código aberto. Esses benefícios se estendem muito além dos poucos por cento de repositórios ativamente mantidos para benefícios mais amplos de implementação cultural.
A Quarta Concepção Errônea: “Você Será Chamado de Volta Quando Sair” #
“when you leave the company they’re going to send you a message 6 months later asking you questions or seeing if you would like to contract with them to upgrade your application there is no such thing as innersourcing”
Recursos às vezes ficam sem manutenção, mas esta não é uma crítica apropriada ao InnerSource em si - é crítica de falhar em implementar InnerSource adequadamente. Esta não é crítica ao InnerSource, mas crítica de carecer de cultura de manutenção onde ninguém mantém o código. Isso resulta de falhar em implementar InnerSource adequadamente ou não considerá-lo de forma alguma - o resultado de carecer de propriedade.
A Analogia DevOps #
Esta é crítica de falhar em fazer InnerSource, não crítica do InnerSource em si. Às vezes isso confunde a lógica. Para colocar isso em termos DevOps: é como dizer “empresas acabam adotando ciclos de revisão lentos de vários meses ou auditorias, ou adicionando processos para decisões de lançamento, então lançamentos se tornam trimestrais ou apenas duas vezes por ano. Portanto DevOps, que afirma permitir lançamentos rápidos, não é bom.” Isso não é porque a metodologia DevOps é ruim, mas simplesmente porque “houve casos onde DevOps não pôde ser implementado.”
Quebrar processos de negócio é extremamente difícil, e muitas empresas disseram que DevOps era impossível. Mas mesmo quando pessoas pensavam que era impossível, havia pioneiros corajosos que trabalharam duro para mudar a cultura e alcançaram DevOps. O mesmo pode acontecer com InnerSource.
A Quinta Concepção Errônea: “Você Deve Possuir Tudo 100%” #
you own it 100% (which implies: InnerSource where you don’t own 100% is impossible)
“InnerSource significa abandonar propriedade de código” está errado. InnerSource na verdade requer que equipes possuam código. Este é um erro comum. Isso é como pessoas que querem abandonar responsabilidade de manutenção e dizem “vamos tornar isso código aberto.” Isso não funciona.
Propriedade Individual vs. de Equipe - InnerSource é Propriedade Forte de Código? #
Primeiro, este “Você” é individual ou plural? Embora indivíduos possam estar listados como arquivo CODEOWNERS em organizações, equipes em última análise mantêm responsabilidade pelo código. Contextualmente, provavelmente está falando sobre Propriedade Forte de Código. Mas isso não é bom quando considerando manutenção organizacional. Porque funcionários podem sair.
InnerSource não é Propriedade Forte de Código. No mínimo, múltiplas pessoas precisam compartilhar responsabilidade. Dito isso, reconheço que Propriedade Forte de Código pode emergir no curto prazo, e nos estágios iniciais de um projeto, vontade individual forte pode naturalmente levar a tais arranjos, mas se você quer alcançar sucesso de longo prazo, é necessário delegar autoridade para que a organização possa lidar com manutenção coletivamente.
Tipos de Propriedade de Equipe - InnerSource é Propriedade Coletiva de Código? #
Este tipo de argumento pode às vezes se referir a Propriedade Coletiva. Neste caso, o argumento também parece sugerir que InnerSource significa propriedade coletiva, mas isso na verdade é diferente. InnerSource não é Propriedade Coletiva de Código InnerSource envolve equipes anfitriãs em última análise lidando com manutenção. InnerSource é Propriedade Fraca de Código. Então embora responsabilidade de manutenção seja 100% correta, dizer “você deve possuir 100% e InnerSource é diferente” é completamente ilógico. Esta é na verdade uma opinião incorreta.
Como Martin Fowler famosamente argumentou sobre propriedade de código, ter todos possuindo código 100% (propriedade coletiva) às vezes cria situações onde ninguém assume responsabilidade. Isso é muito problemático - responsabilidade se torna pouco clara e projetos em última análise falham.
Modelo de Propriedade Fraca de Código #
Em Propriedade Fraca de Código, mantenedores existem, equipes anfitriãs mantêm projetos, e partes específicas podem trazer committers/mantenedores confiáveis de outras equipes. Alguém pode contribuir, alguém pode manter, mas não 100% por “você” ou “sua equipe” - pode ser bem diferente. Por exemplo, 98% do código pode ser possuído por sua equipe, enquanto 2% pode ser possuído por outras equipes.
Neste caso, lembre-se que mesmo se indivíduos são designados como proprietários de código em organizações, equipes em última análise mantêm responsabilidade pelo código. Equipes devem possuí-lo, e não esqueça este ponto importante.
A Sexta Concepção Errônea: “Alguém Vai Jogar 7000 Linhas em Você” #
Every now and then there will be a sufficiently motivated coworker who’s really great and do like a 7,000 line update no explanation but don’t ever fall into this idea that choosing anything for an internal app that you are going to be working on
Ter pull requests de 7000 linhas aparecendo de repente é em si uma falha em introduzir cultura InnerSource - não é algo que acontece fazendo InnerSource. Este caso pode se preocupar que introduzir InnerSource faz tal colaboração acontecer, mas isso está completamente errado.
O Problema Real #
Este argumento representa falhar em implementar cultura InnerSource e práticas colaborativas, não InnerSource em si. Implementações de 7000 linhas são casos muito limitados. Isso representa falha de cultura de colaboração onde 7000 linhas são submetidas como pull requests de repente sem qualquer notificação - a organização deveria corrigir este problema cultural fundamental, que é pré-InnerSource.
Se você quer prevenir isso, há uma solução. Promova cultura InnerSource dentro de sua organização:)
A Realidade: O Que InnerSource Realmente É #
InnerSource é implementação cultural - usando práticas de colaboração de código aberto para desfrutar de vários benefícios que código aberto recebe através de colaboração. O propósito final do InnerSource não é apenas receber contribuições (pull requests), mas inclui solicitações de recursos através de problemas, coordenação de suporte, e vários outros benefícios, além de transparência na tomada de decisão e promoção cultural prática.
Portanto, rejeito definitivamente a alegação de que “implementar melhores práticas de InnerSource para obter pull requests é uma mentira.”
Entendendo a Realidade da Contribuição #
“Nobody ever is going to contribute”
Em colaboração de código aberto, contribuidores são de fato uma fração minúscula. De 1000 usuários, talvez a vasta maioria sejam apenas usuários, 20 podem submeter problemas ou solicitações de recursos, 5 podem enviar pull requests, e talvez apenas um se torne um mantenedor.
Novamente, melhores práticas de InnerSource não farão todas as 1000 pessoas contribuírem. InnerSource ajuda a induzir tal colaboração, mas em última análise visa quebrar silos empresariais, melhorar colaboração que é impedida por restrições organizacionais tradicionais, reduzir tempos de espera de silos de informação, e otimizar alocação de recursos organizacionais usando práticas de código aberto.
Conclusão #
Embora os argumentos neste caso toquem em alguns desafios reais, eles são baseados em mal-entendidos comuns que muitas pessoas encontram quando aprendem sobre InnerSource pela primeira vez. Essas são armadilhas bem conhecidas na comunidade, e é compreensível como alguém pode chegar a essas conclusões sem exploração mais profunda do campo.
A percepção chave é que InnerSource não é sobre forçar práticas de código aberto em uma estrutura rígida. Em vez disso, é sobre retornar à questão fundamental: o que podemos aprender do código aberto? Ao examinar código aberto através de uma lente mais ampla, podemos melhor adaptar esses princípios internamente.
Você pode se juntar a esta conversa e trazer perspectivas frescas. Seja você querendo construir sobre esta discussão, explorar detalhes de implementação mais específicos, ou mesmo desafiar esses argumentos inteiramente - todas as abordagens são bem-vindas. O que importa mais é manter essa perspectiva ampla sobre aprendizados de código aberto e como eles se traduzem para contextos organizacionais internos.
Para informações abrangentes sobre InnerSource, recomendo verificar a InnerSource Commons Foundation. Eles acolhem pontos de vista diversos e diálogo contínuo sobre como princípios de código aberto podem criar valor dentro de organizações.
