Imagine que você é um mantenedor de um projeto de código aberto amplamente usado e usado por desenvolvedores no mundo todo. Ser um mantenedor significa que você decide quais contribuições de colaboradores externos serão aceitas. Agora, há duas contribuições. Uma de um colaborador individual e uma de uma pessoa que você sabe que trabalha para uma determinada empresa. Você sabe que o colaborador individual trabalhou no código que está contribuindo em seu tempo livre e você realmente gosta da qualidade do trabalho dele. A outra contribuição também é de alta qualidade. Você trataria essas contribuições de forma diferente? Você deveria?
Tecnicamente, ambos são apenas pessoas contribuindo com código. Mas você pode realmente ignorar o fato de que um colaborador pertence a uma empresa, ou você atribui sua contribuição principalmente a essa empresa? Uma pesquisa recente da Linux Foundation descobriu que as organizações contribuem com 7,7 bilhões de dólares anualmente para projetos de código aberto e que 86% disso é contribuído na forma de trabalho por indivíduos. Estou interessado no papel que as identidades individuais e empresariais desempenham nas contribuições de código aberto.
Para explorar o tópico, primeiro fornecerei informações básicas sobre Software de Código Aberto e uma visão geral da teoria da identidade em níveis individuais e colaborativos. Em seguida, examinarei a natureza das contribuições individuais no OSS, suas motivações e o papel da comunidade e da meritocracia. Em contraste, explorarei como e por que as empresas contribuem para o OSS e compararei isso com as contribuições individuais e da comunidade. Comparando isso, identifico os principais desafios e tensões entre contribuidores individuais e empresas. Usando a teoria da identidade organizacional introduzida anteriormente, alguns insights interessantes podem ser obtidos. Em seguida, quero dar alguns exemplos práticos que observei trabalhando no ROS.
Contexto: Software de código aberto, Teoria da identidade
Código aberto em sua forma básica significa que o código fonte de um pedaço de software está disponível livremente para qualquer um analisar, modificar ou compartilhar. Na prática, existem diferentes licenças que são publicadas com o código fonte, cada uma com direitos e deveres um pouco diferentes associados a elas. Mas não é sobre isso que falarei hoje. O que torna o código aberto tão poderoso é que esse acesso livre ao código fonte permite uma colaboração verdadeiramente aberta. Eric S. Raymond descreveu isso em dois modelos contrastantes de desenvolvimento de software do "Bazar" e da "Catedral". Aqui, o Bazar se refere à maneira como o software é desenvolvido em projetos de código aberto: aberta e colaborativamente, com muitos colaboradores. O modelo Catedral, por outro lado, simboliza o desenvolvimento de software clássico: fechado dentro de projetos de desenvolvimento comercial por alguns especialistas. Raymond argumenta que o modelo Bazar é mais eficaz para criar software robusto e inovador.
Por razões de transparência, quero declarar que minha análise desses tópicos é influenciada principalmente pela minha experiência pessoal em um projeto de código aberto, que é o ROS, o Robot Operating System. É uma estrutura incrível para construir robôs, mas seus detalhes técnicos não serão mais relevantes para este artigo.
Antes de explorar mais os projetos OSS, no entanto, quero apresentar a ferramenta para essa exploração: identidade . Em termos gerais, identidade é a relação que uma entidade tem consigo mesma 4 . Locke deixou claro que é fundamentalmente a consciência que permite a identidade pessoal . Essa consciência pode ser estendida para trás, para ações ou pensamentos passados. Embora esse seja um bloco de construção fundamental para a identidade, ele sozinho não ajudará a explicar no que estou interessado.
Uma abordagem mais moderna é a identidade social . É "o senso de uma pessoa sobre quem ela é com base em sua filiação a um grupo" 7 . Saber disso pode dar às pessoas um senso de pertencimento, propósito, autoestima e, crucialmente, identidade. Na prática, esses grupos podem ser definidos por qualquer coisa, desde etnia ou religião até afiliação profissional ou preferência musical. Isso também pode explicar aspectos de como as identidades individuais são baseadas em serem empregados por uma empresa. No entanto, tenho uma última seção sobre corporações em particular.
Quando as empresas se referem a si mesmas, isso é chamado de identidade organizacional . Primeiramente, as organizações são mais do que uma coleção de identidades individuais. French argumenta que as organizações como um todo têm moralidade. Basicamente, porque elas têm intencionalidade e responsabilidade 9 . Ao pensar em uma empresa, então é sua capacidade de tomar decisões que leva a essa intencionalidade. Uma organização precisa de uma identidade para tomar essas decisões. E similarmente ao que vimos com Locke acima, isso é baseado em sua própria história, mas também por referência a um tipo de organização autoatribuído. Eu acho isso muito interessante e pode ser usado para explicar muitos fenômenos percebidos ao trabalhar em empresas. Mas por enquanto, isso é contexto suficiente, e a seguir eu quero olhar para a natureza das contribuições de código aberto com mais detalhes.
Contribuições individuais no OSS
Por que indivíduos contribuem para o código aberto? Acho que as principais motivações são intrínsecas. A paixão inerente por programação e desenvolvimento não deve ser subestimada. No entanto, esses projetos OSS também são comunidades, e estar envolvido nisso pode ser muito motivacional. Como aprendemos com a identidade social, pertencer a um grupo é um ingrediente para a própria identidade.
Além disso, motivações extrínsecas também desempenham um papel. Isso inclui o próprio avanço na carreira, porque a contribuição para o código aberto torna o indivíduo visível e pode criar uma reputação que pode ser útil ao procurar um emprego. O reconhecimento externo também pode servir como um fator de motivação mais geral. Sentir-se visto como um contribuidor valioso aumenta a autoestima.
Acho que essa citação resume bem
[As motivações incluem] tanto extrínsecas, melhorando a reputação e desenvolvendo o capital humano e as redes sociais; quanto intrínsecas, satisfazendo as necessidades psicológicas, o prazer e um senso de pertencimento social.
Embora eu tenha falado sobre reconhecimento como uma fonte de motivação, o reconhecimento também serve a um propósito diferente em projetos de código aberto: poder. Projetos de código aberto são frequentemente descritos como meritocracias. Curiosamente, o termo foi popularizado por um livro distópico chamado The rise of the meritocracy, de Michael Young. Nele, a futura sociedade imaginada com base na meritocracia tem muitos problemas, talvez o maior seja a falta de mobilidade social. Uma análise cuidadosa pode refutar os efeitos negativos da meritocracia que Young imaginou em 1958. Então, hoje, a meritocracia é geralmente considerada um sistema político desejável.
Os sistemas políticos observam como o poder é distribuído, e na meritocracia a ideia é que o poder é concedido com base no mérito. É esse mérito que os desenvolvedores individuais acumulam ao contribuir para projetos de código aberto. Com isso, eles ganharão influência na hierarquia do projeto. Isso geralmente permite decisões mais informadas tecnicamente, assumindo que aqueles que contribuíram muito para um projeto também tenham uma ideia clara sobre seu funcionamento interno. Há um contraste óbvio com a forma como o poder é organizado nas empresas, onde as decisões são geralmente por aqueles que têm o direito hierárquico de tomá-las, mas podem não necessariamente ter os insights técnicos relevantes. Isso não quer dizer que nas empresas nenhuma decisão tecnicamente informada seja tomada, mas que o papel e a influência potencial dos engenheiros individuais são diferentes dos projetos de código aberto. Na minha opinião e experiência, essa também é uma razão pela qual as pessoas contribuem para projetos de código aberto.
Note que podem ser feitos argumentos de que estruturas hierárquicas na governança de muitos projetos de OSS também podem aproximá-los de estruturas rígidas de empresas. No entanto, isso não corresponde à minha evidência anedótica pessoal de trabalho em ROS. Embora isso possa ser diferente de projeto para projeto, o tópico geralmente não é, obviamente, uma diferença binária precisa. Mas, apesar das diferenças nas maneiras como as decisões são tomadas, as empresas também têm muitos motivos para se envolver em código aberto, e é isso que quero analisar a seguir.
Contribuições da empresa para o OSS
Por que as empresas estão interessadas em código aberto? Em uma primeira análise, pode parecer contraintuitivo para uma empresa que está geralmente interessada em sucesso financeiro ter interesse em melhorar o software que deve, em última análise, ser e permanecer livre para uso e que é posteriormente compartilhado com todos os seus concorrentes diretos. Mas foi observado por muitos que, embora historicamente fossem os indivíduos que contribuíam principalmente para o código aberto, agora são as empresas. Por que isso?
Uma primeira motivação é a Qualidade . Eric S. Raymond introduziu a lei de Linus como "dados olhos suficientes, todos os bugs são superficiais", que recebeu esse nome em homenagem a Linus Torvalds 3 . E isso certamente faz sentido, que quanto mais pessoas olham para um determinado código, melhor será sua qualidade. Eu diria que isso também pode ser atribuído a como as comunidades de código aberto funcionam. Como qualquer um que tenha trabalhado em grandes projetos de desenvolvimento sabe, ter muitos engenheiros não produzirá automaticamente um software de qualidade. No entanto, eu argumento que também é a organização de um grupo diverso de engenheiros intrinsecamente motivados em estruturas meritocráticas que leva à melhoria constante da qualidade do software. Mas a promessa de qualidade não pode ser a única motivação para empresas que investem esses 7,7 bilhões de dólares anualmente em projetos de código aberto.
Fica realmente interessante olhar para a Inovação . Historicamente, seria considerado uma tarefa inerente de uma empresa criar inovação por si mesma. No entanto, o avanço cada vez maior do estado da arte técnica pode tornar desafiador acompanhar isso, muito menos estendê-lo por meio da inovação. O OSS ajuda aqui nivelando o campo de jogo. Quando o estado da arte está disponível para todos usarem, não é necessário reinventar a roda. Empresas individuais podem concentrar suas equipes de desenvolvimento para investir no que elas acham que é inovador. Isso também é o que torna esses projetos extremamente interessantes para empresas menores, porque os efeitos descritos são ainda mais pronunciados para elas.
Se as empresas constroem sua capacidade de inovação e, portanto, às vezes, todo o seu modelo de negócios, em software de código aberto, é natural que elas tenham interesse no bem-estar do projeto OSS associado. É por isso que muitas empresas apoiam esses projetos monetariamente. No entanto, essa dependência também motiva o desejo de influência. A influência estratégica de longo prazo é frequentemente concedida pelo projeto OSS em troca do suporte financeiro. Para influência técnica de curto prazo, muitas vezes também é do interesse das empresas pagar seus desenvolvedores para contribuir ativamente com o software. Essa influência também pode ser mais direcionada, mas muitas vezes requer a construção de contribuidores com a influência necessária a longo prazo 16 . Um ponto muito interessante na pesquisa da Linux Foundation foi que muitos entrevistados eram relativamente mais informados sobre o tamanho de suas contribuições financeiras do que sobre a contribuição por meio do trabalho.
Desafios e tensões
À primeira vista, isso parece um relacionamento mutuamente benéfico: engenheiros querem contribuir, empresas os deixam fazer isso e ganhar influência. No entanto, isso também traz desafios. Por exemplo, não é fácil para as empresas saberem qual influência elas querem ou precisam a longo prazo. Também pode ser desafiador para um engenheiro que vê a necessidade de tal influência convencer seu empregador a fazer os investimentos necessários. Aqui, é interessante pensar sobre a qual identidade esse mérito será então vinculado: a da empresa ou a do engenheiro individual? Pela minha experiência, geralmente é o indivíduo, até um grau em que essas pessoas levam seu mérito com elas quando mudam de emprego. Obviamente, isso não é do interesse das empresas que investiram especificamente naquela pessoa e projeto. No entanto, por meio de um trabalho cuidadoso de estratégia de OSS de longo prazo, também é muito viável para as empresas acumularem mérito e não perdê-lo em mudanças de pessoal.
Outro desafio muito real para colaboradores e mantenedores individuais destacado por Nadia Eghbal e outros é o esgotamento. Esse fenômeno pode muito bem ser inerente à governança insuficiente no gerenciamento de projetos OSS. Especialmente em risco de esgotamento estão os mantenedores que preenchem cargos muito personalizados para sua pessoa e/ou conjunto de habilidades. A governança eficaz definiria processos para distribuir sua carga de trabalho para mais pessoas ou encontrar pessoas para intervir caso precisem fazer uma pausa ou cuidar de tarefas pessoais. Muitas vezes, também é simplesmente improvável encontrar outra pessoa assumindo a posição dessa pessoa. Se eles estão fazendo um bom trabalho, ninguém contestará sua posição, e se sua carga de trabalho for percebida como basicamente mais do que um trabalho de tempo integral, isso se torna ainda menos provável. A relação com as identidades da empresa é mais fraca aqui: o fenômeno descrito geralmente se aplica a indivíduos cuja identidade é muito mais relevante para seu sucesso do que a de sua empresa, se isso for relevante. No entanto, isso traz uma realidade trágica de que muitas outras empresas dependem do trabalho dessa pessoa sem serem capazes de garantir suas condições de trabalho adequadas. Agora, acho que podemos analisar esses desafios mais de perto com mais teoria da identidade.
Teoria da Identidade Organizacional Aplicada ao OSS
Um aspecto interessante no artigo de Whetten é que identidades organizacionais são mais fluidas do que identidades pessoais. É pelo menos isso que eu deduzo dele, e faz sentido, porque como pessoa eu confio muito mais nessa identidade e ela pode causar uma crise séria se for desafiada ou mudar muito. No entanto, identidades de empresas serão desafiadas com mais frequência e geralmente são definidas adequadamente apenas em eventos de mudança ou crise. Isso explica como o mérito em OSS é mais fortemente atribuído a identidades individuais se elas forem mais constantes. No entanto, também é visível que uma condição necessária para alocação de mérito a corporações requer uma forte identidade organizacional. Isso é, claro, também influenciado pelas identidades individuais de engenheiros sendo afiliados a essas corporações em contextos públicos como projetos de OSS.
Outro elo interessante pode ser extraído do argumento de French para a moralidade das corporações 9 . Se alguém alega que empresas que usam software de código aberto devem dar contribuições em troca, essa é uma declaração moral. Isso ganharia ou perderia validade com base na atribuição de moralidade às empresas. Antes de ler o artigo de French, eu pessoalmente não teria assumido que as empresas eram morais. Além disso, eu também não achava que a moralidade fosse muito relevante no contexto de empresas contribuindo (ou não) para o código aberto. No entanto, acho que podemos aprender algo aplicando o argumento de French ao código aberto: o argumento é baseado em intencionalidade e responsabilidade. Isso faz sentido intuitivo para mim, que eu só posso ser moralmente responsável por ações que fiz intencionalmente e pelas quais sou responsável. Quando aplicamos isso a uma empresa que pretende usar software de código aberto e é responsável por esse uso, somente então ela seria moralmente obrigada a contribuir de volta. O que acontece sem intencionalidade é interessante: se a organização não pretendia usar esse código-fonte aberto, por exemplo, porque um funcionário decidiu usá-lo sem obter a aprovação adequada, isso não implica necessariamente a necessidade moral de uma decisão no nível da empresa para contribuir de volta. E para responsabilidade, poderíamos considerar o exemplo de uma empresa não ser responsável pelo uso de um determinado software de código-fonte aberto, talvez porque eles são forçados a usá-lo por outro parceiro de negócios, então eu também posso seguir o argumento de que eles não seriam moralmente obrigados a contribuir de volta. É muito fascinante para mim como atributos como moralidade, que são bem compreendidos por agentes individuais, podem ser aplicados claramente às organizações. Aqui, o código-fonte aberto funciona como um ótimo exemplo que ajuda a esclarecer essas ideias.
Estudos de caso e exemplos
Para tornar esses pontos ainda mais compreensíveis, gostaria de adicionar alguns exemplos práticos que observei no ROS. Um aspecto que não sei o quão único ele é em comparação a outros projetos é a prevalência de pequenas empresas ou colaboradores que têm seus próprios negócios autônomos. Isso serve, por um lado, como uma lente interessante sobre a moralidade das empresas, que é ainda mais fácil de acreditar quanto mais próxima uma empresa estiver de um único indivíduo. Por outro lado, também destaca a importância de colaboradores individuais no OSS. Muitas dessas empresas não são apenas pequenas, mas também mudam constantemente, o que torna as pessoas um aspecto mais constante da comunidade do que suas empresas. Aqui, tenho uma observação que discordaria de Schrape escrevendo que "empresas e outras organizações são capazes de trazer seus recursos de forma mais contínua e consistente do que colaboradores individuais". No ROS, e particularmente no Nav2, testemunhamos algumas empresas descontinuando suas contribuições, enquanto o envolvimento dos indivíduos relevantes parece muito mais estável e consistente.
Sobre a relevância e importância das identidades para o trabalho em código aberto, me deparei com uma discussão no Stack Overflow, onde uma pessoa pergunta se seria viável contribuir com tudo o que sua empresa faz a partir de uma conta do GitHub. O consenso das respostas é que essa é uma má ideia por vários motivos, um deles sendo a relevância integral da comunicação pessoal em comunidades de OSS. Há também uma boa postagem de blog de Jono Bacon sobre se contribuições anônimas de OSS são uma boa ideia, chegando à conclusão de que identidades em OSS são importantes por razões de meritocracia, responsabilidade e abertura. Esses são pontos válidos para a relevância de identidades individuais em código aberto de perspectivas muito práticas.
No entanto, há também um exemplo interessante para identidades organizacionais em um nível que não consideramos até agora. Esse exemplo é, curiosamente, a própria comunidade ROS. Podemos aplicar o que aprendemos sobre a necessidade de discussão sobre uma identidade organizacional e o potencial para dar início a essa discussão por meio de grandes mudanças e da ameaça de perda de identidade. O exemplo é, claro, a aquisição de grandes partes da Open Robotics pela Intrinsic em 2022. Isso levou a muitas discussões na comunidade ROS e, finalmente, à fundação de sua nova organização de governança Open Source Robotics Alliance OSRA. Então, leio isso como um exemplo para a ROS como uma organização perdendo sua identidade por meio da aquisição da Intrinsic e a subsequente redefinição de sua própria identidade, terminando em uma identidade mais clara e melhor compreendida do que antes. E somente essa nova identidade poderia ter levado à forte posição que a OSRA tem hoje.
Conclusão
As principais conclusões que podem ser úteis neste artigo são:
- Tensão entre mérito individual e organizacional : contribuições em projetos de código aberto são frequentemente vinculadas a identidades individuais em vez das empresas que representam. Para utilizar isso como uma empresa, uma forte estratégia de código aberto é necessária.
- Meritocracia vs. Hierarquia : Projetos de código aberto frequentemente operam como meritocracias, onde a influência é conquistada por meio de contribuições. No entanto, a governança do projeto também contém elementos de hierarquias clássicas. Esse equilíbrio é crucial.
- Motivações Duplas para Contribuições : Indivíduos são movidos por fatores intrínsecos, como paixão pelo desenvolvimento e pertencimento à comunidade, e fatores extrínsecos, como avanço na carreira e reputação. Empresas, no entanto, são motivadas por objetivos como melhoria de qualidade, inovação e influência de longo prazo sobre projetos de código aberto.
- Papel da identidade organizacional : as empresas podem estabelecer sua identidade dentro da comunidade de código aberto por meio de contribuições consistentes e intencionais, o que ajuda a construir confiança e influência ao longo do tempo.
- Desafios de governança em código aberto : o esgotamento entre os mantenedores destaca a necessidade de melhores estruturas de governança em projetos de código aberto, como processos para distribuir cargas de trabalho e garantir a continuidade, o que pode diferir significativamente das práticas corporativas de gerenciamento de projetos.
Um grande agradecimento a Maximilian Roßmann e Sebastian Castro por refinarem tanto o conteúdo quanto a linguagem. Não teria conseguido sem vocês!
Boysel, Sam, Frank Nagle, Hilary Carter, Anna Hermansen, Kevin Crosby, Jeff Luszcz, Stephanie Lincoln, Daniel Yue, Manuel Hoffmann e Alexander Staub. 2024. “Relatório de financiamento de software de código aberto de 2024.” https://opensourcefundingsurvey2024.com/ .
Raymond, Eric S. 2001. The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary . 1ª edição. Oxford, Reino Unido: O'Reilly Media.
Noonan, Harold e Ben Curtis. 2022. “Identidade.” Em The Stanford Encyclopedia of Philosophy , editado por Edward N. Zalta e Uri Nodelman, outono de 2022. Metaphysics Research Lab, Universidade Stanford.
Locke, John. 1694. “Um ensaio sobre o entendimento humano.”
Gordon-Roth, Jessica. 2020. “Locke sobre identidade pessoal.” Em Stanford Encyclopedia of Philosophy , primavera de 2020.
Turner, JC, RJ Brown e H. Tajfel. 1979. “Comparação social e interesse de grupo no favoritismo do grupo interno”. European Journal of Social Psychology 9 (2): 187–204. https://doi.org/10.1002/ejsp.2420090207 .
“Teoria da identidade social em psicologia (Tajfel & Turner, 1979).” 2023. https://www.simplypsychology.org/social-identity-theory.html .
Francês, Peter A. 1979. “A corporação como pessoa moral”. AMERICAN PHILOSOPHICAL QUARTERLY 16 (3): 5–13. https://www.jstor.org/stable/20009760 .
Português Whetten, David A. 2006. “Albert e Whetten revisitados: fortalecendo o conceito de identidade organizacional.” Journal of Management Inquiry 15 (3): 219–34. https://doi.org/10.1177/1056492606291200 .
Benkler, Yochai. 2004. “Estratégias baseadas em bens comuns e os problemas das patentes.” Science 305 (5687): 1110–11. https://doi.org/10.1126/science.1100526 .
Young, Michael. 1958. A ascensão da meritocracia .
Allen, Ansgar. 2011. “ A ascensão da meritocracia de Michael Young: uma crítica filosófica.” British Journal of Educational Studies 59 (4): 367–82. https://doi.org/10.1080/00071005.2011.582852 .
Schrape, Jan-Felix. 2018. “Comunidades de código aberto: a institucionalização sociotécnica da invenção coletiva.” Em Coletividade e poder na Internet , 57–83. Cham: Springer International Publishing. https://doi.org/10.1007/978-3-319-78414-4\4 .
“A evolução dos contribuidores de código aberto: de amadores a profissionais.” nd Acessado em 1º de janeiro de 2025.https://www.redhat.com/en/blog/evolution-open-source-contributors-hobbyists-professionals .
“Participando de comunidades de código aberto”. Acessado em 1º de janeiro de 2025. https://www.linuxfoundation.org/resources/open-source-guides/participating-in-open-source-communities .
Nadia Eghbal. 2020. Trabalhando em público: a criação e manutenção de software de código aberto . São Francisco: Stripe Press.
“Por que contribuir para o código aberto é assustador e como contribuir de qualquer maneira Authentik.” nd Acessado em 1 de janeiro de 2025. https://goauthentik.io/blog/2024-03-07-why-contributing-to-open-source-is-scary/ .
“Mudanças no WG de Navegação2 e AJUDA PROCURA-SE - ROS de próxima geração.” 2021. ROS Discourse . https://discourse.ros.org/t/navigation2-wg-changes-and-help-wanted/12348 .
“[Nav2] Um tempo para mudança - Geral.” 2021. ROS Discourse . https://discourse.ros.org/t/nav2-a-time-for-change/30525 .
“Contribuidor - Contribuindo como uma empresa - Open Source Stack Exchange.” Acessado em 1º de janeiro de 2025. https://opensource.stackexchange.com/questions/9763/contributing-as-a-company .
“Projetos anônimos de código aberto - Jono Bacon.” 2017. https://www.jonobacon.com/2017/04/28/anonymous-open-source-projects/ .
“Intrinsic da Alphabet adquire a maioria da Open Robotics - IEEE Spectrum.” Acessado em 24 de janeiro de 2025. https://spectrum.ieee.org/alphabet-intrinsic-open-robotics-acquisition .
“Questões sobre a aquisição intrínseca do OSRC.” nd ROS Discourse . Acessado em 24 de janeiro de 2025. https://discourse.ros.org/t/questions-about-the-intrinsic-acquisition-of-osrc/28763 .
“Anunciando a Open Source Robotics Alliance.” nd Open Robotics . Acessado em 24 de janeiro de 2025. https://www.openrobotics.org/blog/2024/3/18/announcing-the-open-source-robotics-alliance-osra .
