Artigo

Ana Paula Calistro Lopes de Oliveira; Juliano Schimiguel

DOI: 10.22167/2675-6528-202601571

Artigo derivado de Trabalho de Conclusão de Curso (TCC), com conteúdo baseado no trabalho original do aluno e adaptado ao formato editorial da Revista E&S com apoio da ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege para síntese e organização textual.

Resumo

O uso corporativo de softwares de código aberto (OSS) expandiu-se significativamente, impulsionado por flexibilidade e inovação, mas introduziu desafios de governança e sustentabilidade, visto que a continuidade desses projetos depende do engajamento de comunidades externas. Diante da lacuna entre métricas técnicas e o apoio à decisão estratégica, propôs-se um framework de avaliação de riscos para OSS, fundamentado em três dimensões: continuidade, agilidade e sustentabilidade. A abordagem foi explorada por meio de um estudo de caso múltiplo, que analisou os repositórios Kubernetes, React e Moby, utilizando dados da plataforma OSS Insight. Foram considerados indicadores como Elephant Factor (EF), Contributor Absence Factor (CAF), Time to Merge (TTM), Response Time e Backlog Management Index (BMI), organizados em um modelo visual de “faróis”. Os resultados revelaram diferenças importantes entre os projetos, com Kubernetes demonstrando maior resiliência institucional, enquanto React e Moby apresentaram riscos mais elevados, principalmente devido à concentração de conhecimento. O framework mostrou-se eficaz ao converter dados operacionais complexos em uma matriz de apoio à decisão, capacitando organizações a fundamentar escolhas tecnológicas entre adoção estratégica, monitoramento ativo ou mitigação de riscos em ambientes de alta criticidade.

Palavras-chave: Análise de Projetos; Ecossistemas de Software; Governança de Software; Métricas de Engenharia de Software; Sustentabilidade de OSS.

1. Introdução

A crescente adoção de software de código aberto (Open Source Software – OSS) tem transformado significativamente o desenvolvimento de sistemas digitais e a infraestrutura tecnológica de organizações em todo o mundo. Impulsionado por fatores como a flexibilidade inerente, a capacidade de inovação acelerada e a redução de custos operacionais, o OSS tornou-se um pilar fundamental para grande parte das aplicações corporativas. Atualmente, bibliotecas, softwares e componentes mantidos por comunidades distribuídas compõem uma parcela substancial das bases de código. Conforme o relatório Open Source Security and Risk Analysis (SYNOPSYS, 2024), aproximadamente noventa e seis por cento das bases de código auditadas contêm componentes OSS. Em setores estratégicos como telecomunicações e fintechs, a participação do OSS no código total pode atingir entre setenta e oitenta por cento.

Apesar dos benefícios evidentes, a dependência crescente de softwares de código aberto introduz desafios relevantes, especialmente no que tange à governança, continuidade e segurança dos sistemas. Diferentemente das soluções proprietárias, cuja manutenção é regida por contratos formais e acordos de nível de serviço bem definidos, a longevidade e a capacidade de resposta do OSS dependem intrinsecamente da dinâmica e do engajamento de comunidades externas, cuja estabilidade e capacidade de resposta não são sempre garantidas. Nesse contexto, a falta de maturidade na governança de componentes OSS expõe as organizações a riscos operacionais críticos, conforme evidenciado no 9th Annual State of the Software Supply Chain (SONATYPE, 2023). O relatório destaca que a dependência de projetos com manutenção deficitária ou governança instável constitui um dos principais vetores de vulnerabilidades na cadeia de suprimentos de software moderna.

Uma vez integrado ao ecossistema corporativo, o software de código aberto torna-se um ativo de longo prazo, com potencial para permanecer em uso por muitos anos. Contudo, a saúde de um projeto externo é um fator dinâmico e pode mudar ao longo do tempo. Um software que era considerado seguro e frequentemente atualizado no momento de sua adoção pode, posteriormente, sofrer degradação em sua governança ou ser abandonado pela comunidade. Essa evolução cria riscos ocultos de continuidade para as organizações que dependem desses componentes, impactando a previsibilidade e a segurança de suas operações.

A literatura de engenharia de software aponta para diversos fatores determinantes na sustentabilidade de projetos OSS. Elementos como a distribuição de contribuições, a capacidade de resposta a demandas e a gestão eficaz do backlog são consistentemente identificados como cruciais para a saúde e evolução desses projetos (RICCA et al., 2011; FORSGREN et al., 2018; SONATYPE, 2023). No entanto, esses indicadores são frequentemente analisados de forma isolada, o que dificulta sua utilização estruturada como um instrumento prático de apoio à tomada de decisão em contextos organizacionais complexos.

Diante desse cenário, observa-se uma lacuna significativa entre a disponibilidade de métricas técnicas detalhadas e sua aplicação prática na avaliação de riscos associados ao uso de OSS. Em particular, há uma ausência de modelos que consigam integrar múltiplos indicadores de forma interpretável, permitindo a identificação sistemática e comparável de fragilidades estruturais em projetos de software de código aberto. Essa lacuna impede que as organizações tomem decisões tecnológicas mais informadas e estratégicas.

Assim, este estudo justifica-se pela necessidade de fornecer às organizações uma ferramenta robusta para navegar pelos riscos inerentes ao uso de software de código aberto, e tem como objetivo propor um framework de avaliação de riscos para organizações que utilizam OSS, baseado em indicadores quantitativos e voltado ao apoio à tomada de decisão, considerando as dimensões de continuidade, agilidade e sustentabilidade.

2. Material e Métodos

A pesquisa foi delineada como um estudo de natureza aplicada e descritiva, conforme Gil (2022). Adotou-se uma abordagem de estudo de caso múltiplo para a observação técnica de fenômenos contemporâneos em ecossistemas de software de código aberto (OSS). Essa estratégia visou compreender as dinâmicas de governança e sustentabilidade em diferentes contextos de projetos OSS, alinhando-se ao objetivo de propor um framework de avaliação de riscos.

O estudo analisou três repositórios de software de código aberto: Kubernetes, React e Moby. A seleção intencional desses projetos visou representar diferentes modelos de governança (institucionais, corporativos e mistos), permitindo uma avaliação comparativa do framework em variados níveis de risco e dinâmicas de contribuição. A coleta de dados abrangeu um período de doze meses, focando nas atividades mais recentes dos projetos.

A coleta de dados empregou a plataforma OSS Insight (PingCAP, 2023), ferramenta especializada na análise de projetos de código aberto. O OSS Insight agrega informações do GitHub Archive (GitHub Archive, 2023), repositório público que registra atividades no GitHub (GitHub, Inc., 2023), plataforma central para desenvolvimento colaborativo. As informações extraídas foram organizadas e consolidadas no Microsoft Excel para processamento e análise.

A coleta de dados brutos, realizada na plataforma OSS Insight, focou em eventos dos últimos doze meses. Extraíram-se informações detalhadas sobre pull requests (abertura, integração, autoria) e issues (abertura, fechamento, tempo de resposta). Identificaram-se também contribuidores, volume de participação e dados de afiliação corporativa, quando disponíveis. Esses dados secundários constituíram a base para a análise dos indicadores de risco.

O percurso metodológico adotado neste estudo foi estruturado em etapas sistemáticas, visando a clareza e a reprodutibilidade dos procedimentos. A Figura 1 ilustra o fluxo completo da execução da pesquisa, desde a seleção dos objetos de estudo até a proposição de ações para a tomada de decisão.

Figura 1. Detalhamento da execução da pesquisa

Fonte: Dados originais da pesquisa

Conforme apresentado na Figura 1, a metodologia desdobrou-se em cinco passos principais: seleção dos objetos de estudo, extração de dados brutos, tratamento e consolidação das informações, categorização e aplicação do framework, e, por fim, a sugestão de ações para apoio à tomada de decisão. Cada etapa foi crucial para a construção e validação do modelo de avaliação de riscos.

Os dados coletados foram organizados e consolidados no Microsoft Excel, com cálculos estatísticos descritivos para comparação entre repositórios. Para a análise, empregaram-se cinco indicadores quantitativos: Elephant Factor (EF), conforme CHAOSS (2019); Contributor Absence Factor (CAF), discutido por Avelino et al. (2016); Time-to-Merge (TTM), utilizado por Gousios et al. (2014); Response Time, conforme Steinmacher et al. (2015) e Jiang et al. (2017); e Backlog Management Index (BMI), empregado por Kalliamvakou et al. (2016). Esses indicadores foram agrupados em três dimensões analíticas – continuidade, agilidade e sustentabilidade – para estruturar a avaliação de risco dos projetos OSS.

O framework de avaliação de riscos foi aplicado em três etapas: coleta de dados operacionais dos repositórios; cálculo e análise dos indicadores de risco; e classificação dos resultados em níveis de risco. Para cada indicador, estabeleceram-se limites críticos (thresholds) que permitiram classificar o risco em baixo (verde), médio (amarelo) e alto (vermelho). Essa classificação visual facilitou a interpretação e o apoio à tomada de decisão.

Os dados utilizados são secundários, de acesso público e sem identificação direta de indivíduos, dispensando submissão a comitê de ética. Contudo, o estudo reconhece limitações metodológicas, como a ausência de informações completas sobre a afiliação organizacional de contribuidores no GitHub, impactando a precisão de métricas. Os limiares de classificação de risco foram definidos operacionalmente, dada a inexistência de valores universais na literatura. A natureza quantitativa das métricas também não captura aspectos qualitativos, como governança ou criticidade das contribuições. A generalização dos achados é limitada ao conjunto de projetos e ao recorte temporal analisado.

3. Resultados e Discussão

A aplicação do framework de avaliação de riscos aos projetos Kubernetes, React e Moby permitiu uma análise detalhada do comportamento de seus repositórios, à luz das dimensões de continuidade, agilidade e sustentabilidade. Inicialmente, as métricas foram avaliadas individualmente para compreender seu desempenho e as implicações específicas para cada projeto. Posteriormente, realizou-se uma análise integrada, culminando na atribuição de um valor consolidado de risco para cada repositório e na proposição de recomendações estratégicas para a tomada de decisão, conforme delineado no objetivo do estudo.

Os resultados revelaram perfis de risco distintos entre os projetos analisados, destacando a complexidade da governança de software de código aberto. A interpretação dos dados, baseada nos indicadores Elephant Factor (EF), Contributor Absence Factor (CAF), Time to Merge (TTM), Response Time e Backlog Management Index (BMI), forneceu uma visão abrangente sobre as fragilidades e pontos fortes de cada ecossistema, permitindo que as organizações avaliem a dependência e a saúde de componentes OSS de forma mais estruturada e informada. Risco de Continuidade

A análise da dimensão de continuidade, focada nos indicadores Elephant Factor (EF) e Contributor Absence Factor (CAF), revelou padrões variados de concentração de conhecimento e dependência organizacional. No projeto Kubernetes, aproximadamente 51% das contribuições foram classificadas como desconhecidas, o que limita a identificação precisa da afiliação organizacional. Contudo, entre as organizações identificadas, Red Hat (8%), Google (7%) e Microsoft (2%) representam parcelas relativamente pequenas, indicando uma distribuição de contribuições que sugere baixo risco de concentração organizacional, conforme os critérios do framework.

Em relação ao Contributor Absence Factor (CAF) para Kubernetes, o principal colaborador individual responde por cerca de 2,4% das contribuições, e os quatro colaboradores subsequentes concentram aproximadamente 27%. A cauda longa, que engloba os demais contribuidores, abrange cerca de 62% do total. Essa distribuição indica uma baixa concentração de contribuições em indivíduos específicos, sugerindo uma dispersão do conhecimento e, consequentemente, um baixo risco associado à dependência de colaboradores-chave, o que reforça a resiliência institucional do projeto.

No projeto React, a maioria dos contribuidores foi classificada como desconhecida no cálculo do Elephant Factor (EF), o que, à primeira vista, indicaria baixo risco organizacional. No entanto, essa interpretação exige cautela, pois o React é um projeto mantido pela Meta Platforms, com forte influência corporativa, apesar de sua licença permissiva (GITHUB, 2024; REACT, 2024). A limitação da métrica EF, quando baseada exclusivamente em dados de afiliação organizacional do GitHub, pode mascarar a real concentração de poder.

A análise do Contributor Absence Factor (CAF) para o React, por sua vez, revelou que aproximadamente 50% das contribuições estão concentradas em um grupo reduzido de seis colaboradores. Esse achado aponta para uma concentração significativa de conhecimento, classificando o projeto em um nível de risco intermediário. Essa dependência de contribuidores-chave é um fator crítico, pois a saída desses indivíduos pode impactar a continuidade e a evolução do projeto, evidenciando a necessidade de uma análise complementar entre as métricas.

Para o projeto Moby, a análise do Elephant Factor (EF) também indicou uma baixa concentração organizacional aparente, com cerca de 48% das contribuições classificadas como desconhecidas, seguidas por Docker (12%), Mirantis (3,9%) e Microsoft (2,6%). Essa distribuição, similar ao React, sugere diversidade organizacional. Contudo, a alta proporção de contribuições não identificadas pode comprometer a precisão dessa interpretação, potencialmente ocultando concentrações reais de participação institucional.

Em contraste, a análise do Contributor Absence Factor (CAF) para Moby revelou uma forte concentração de contribuições em poucos indivíduos. O principal colaborador é responsável por aproximadamente 35% das contribuições, e os cinco principais concentram cerca de 61,5% do total. Esse padrão indica uma dependência significativa de contribuidores-chave e um elevado risco associado à centralização do conhecimento, classificando o projeto em risco médio. A divergência entre EF e CAF ressalta a importância de analisar ambas as métricas para uma avaliação robusta da sustentabilidade do projeto. Risco de Agilidade

A dimensão de agilidade foi avaliada por meio do Response Time e do Time to Merge (TTM), métricas que refletem a capacidade de resposta da comunidade e a eficiência do processo de integração de código. A análise conjunta dessas métricas é crucial, pois representam etapas distintas do fluxo de contribuições: a triagem inicial e a integração das mudanças, respectivamente. A comparação entre os projetos Kubernetes, React e Moby evidenciou padrões de agilidade distintos.

No Kubernetes, o Response Time apresentou um desempenho de baixo risco, com uma mediana de aproximadamente 8 segundos e um p75 de cerca de 9 segundos, indicando uma resposta inicial praticamente imediata às solicitações. No entanto, o Time to Merge (TTM) revelou valores significativamente mais elevados, com uma mediana de aproximadamente 21,5 dias e um p75 de cerca de 170 dias, ambos classificados como alto risco. Esses resultados evidenciam um descompasso entre a rapidez na triagem e o tempo prolongado necessário para a integração das contribuições, sugerindo gargalos no fluxo de desenvolvimento.

O projeto React demonstrou um desempenho consistente em ambas as métricas. O Response Time apresentou uma mediana de aproximadamente 1 hora (baixo risco) e um p75 de cerca de 2 dias (médio risco). O Time to Merge (TTM) registrou uma mediana de aproximadamente 16,5 horas e um p75 de cerca de 4,5 dias, ambos classificados como baixo risco. Esses dados indicam um alinhamento eficaz entre a resposta inicial e a integração das contribuições, com tempos reduzidos ao longo de todo o fluxo de desenvolvimento.

O Moby apresentou um comportamento distinto. O Response Time teve uma mediana de aproximadamente 1 dia (médio risco) e um p75 de cerca de 16 dias (alto risco), indicando maior variabilidade e atrasos na resposta inicial da comunidade. Em contrapartida, o Time to Merge (TTM) apresentou uma mediana de aproximadamente 9,5 horas e um p75 de cerca de 5 dias, ambos classificados como baixo risco. Esse padrão sugere que, embora a resposta inicial seja mais lenta, o tempo de integração das contribuições é eficiente após o início do processo.

De forma comparativa, os resultados indicam que a agilidade no fluxo de contribuições não depende exclusivamente da rapidez em uma única etapa, mas da consistência entre a triagem e a integração. O Kubernetes, por exemplo, apresenta baixo desempenho na integração, apesar da rápida resposta inicial. O Moby exibe o comportamento inverso, com resposta inicial mais lenta, mas integração eficiente. O React, por sua vez, demonstra maior equilíbrio entre as métricas, com tempos reduzidos em ambas as etapas, reforçando a importância da análise conjunta para uma avaliação precisa da agilidade em projetos de software. Risco de Sustentabilidade

A análise do Backlog Management Index (BMI) permitiu avaliar a capacidade de cada projeto em manter sua evolução frente ao acúmulo de demandas, indicando a saúde do projeto em termos de gestão de pendências. Essa métrica expressa o equilíbrio entre o número de issues fechadas e abertas no período analisado, sendo um indicador crucial da eficiência do processo de desenvolvimento e da sustentabilidade a longo prazo.

O Kubernetes apresentou um BMI de aproximadamente 111,8%, sendo classificado como baixo risco. Esse valor indica que o volume de issues resolvidas superou o de issues abertas no período analisado, caracterizando um cenário de redução do backlog. Isso evidencia uma capacidade adequada do projeto em absorver e processar novas demandas, contribuindo para sua sustentabilidade e previsibilidade.

O React registrou um BMI de aproximadamente 95,9%, classificando-o como médio risco. Esse resultado sugere um equilíbrio próximo entre a entrada e a resolução de demandas, com uma leve predominância na abertura de issues. Embora o sistema demonstre relativa estabilidade, observa-se uma tendência moderada de acúmulo de backlog, o que demanda monitoramento contínuo para evitar que essa tendência se agrave e comprometa a eficiência futura do projeto.

De forma semelhante, o Moby apresentou um BMI de aproximadamente 86,1%, também classificado como médio risco. Esse valor indica um desequilíbrio mais acentuado entre a entrada e a resolução de demandas em comparação ao React, sugerindo uma maior propensão ao crescimento do backlog ao longo do tempo. Esse cenário aponta para a necessidade de atenção à gestão de pendências para garantir a sustentabilidade do projeto a longo prazo e evitar a degradação da eficiência operacional. Análise Integrada das Métricas

A partir da aplicação do framework de risco, foi possível consolidar a classificação das métricas para cada projeto, utilizando o modelo visual de “faróis” (verde para baixo risco, amarelo para médio risco e vermelho para alto risco). Essa consolidação permite uma visão holística do perfil de risco de cada repositório, facilitando a tomada de decisão estratégica por parte das organizações que utilizam esses softwares.

Para o Kubernetes, a análise integrada revelou um perfil de baixo risco em continuidade (EF e CAF) e sustentabilidade (BMI), mas um alto risco na agilidade (TTM). Isso sugere que, embora o projeto tenha uma governança distribuída e uma boa capacidade de gestão de backlog, o tempo de integração de novas contribuições é um gargalo significativo. As ações recomendadas para o Kubernetes incluem a identificação do impacto do TTM em mudanças críticas e a redução da dependência do repositório oficial por meio de estratégias como patches locais ou manutenção de forks.

O projeto React apresentou um perfil de risco moderado na dimensão de continuidade (CAF) e sustentabilidade (BMI), mas um baixo risco na agilidade (Response Time e TTM). A concentração de conhecimento em poucos contribuidores (CAF) e a leve tendência de acúmulo de backlog (BMI) são pontos de atenção. As recomendações para o React envolvem o mapeamento de contribuidores críticos para promover a distribuição de conhecimento e o monitoramento da evolução do backlog, avaliando o impacto em demandas prioritárias para mitigar riscos de atrasos na evolução do sistema.

O Moby demonstrou o cenário mais crítico, com riscos moderados na continuidade (CAF) e sustentabilidade (BMI), e alto risco na agilidade (Response Time). A lenta resposta inicial da comunidade (Response Time) é um fator preocupante, indicando possível limitação na capacidade de interação. As ações sugeridas para o Moby incluem a redução da dependência desse canal por meio de suporte alternativo, como serviços especializados ou desenvolvimento de capacidade interna, além do monitoramento do backlog e a adoção de soluções internas para demandas críticas.

Esses achados reforçam a perspectiva da literatura de engenharia de software, que indica que o desempenho e a sustentabilidade de projetos dependem da interação entre diferentes etapas do fluxo de desenvolvimento, especialmente no que se refere à capacidade de resposta, integração e resolução de demandas (Forsgren et al., 2018; Reinertsen, 2009). A análise conjunta das métricas permite uma compreensão mais robusta dos riscos associados ao uso de software OSS no contexto corporativo, apoiando decisões mais informadas quanto à mitigação ou aceitação desses riscos. Limitações dos dados e oportunidades de melhoria

O presente estudo identificou limitações relacionadas à qualidade dos dados obtidos do GitHub, especialmente no que se refere à ausência de informações sobre a afiliação organizacional de diversos contribuidores. Embora a métrica Elephant Factor (EF) seja adequada para identificar concentração organizacional, a elevada proporção de registros classificados como desconhecidos compromete sua precisão. Esse aspecto é particularmente relevante no caso do React, que, apesar de apresentar alto percentual de contribuidores sem identificação organizacional, é reconhecidamente influenciado pela Meta.

Nesse contexto, a métrica Contributor Absence Factor (CAF) complementa a análise ao evidenciar a concentração de conhecimento em poucos indivíduos, uma vez que seis colaboradores concentram aproximadamente 60% das solicitações de integrações ao repositório (Pull Requests), indicando dependência significativa de contribuidores-chave. Essa limitação pode impactar diretamente métricas como o Elephant Factor (EF), podendo subestimar a concentração organizacional e, consequentemente, influenciar a interpretação do risco. Diante disso, uma oportunidade de melhoria consiste no uso de estratégias de enriquecimento de dados, como a integração com fontes complementares ou a aplicação de técnicas de inferência para identificação de afiliação organizacional, de modo a aumentar a precisão das métricas relacionadas à estrutura de governança dos projetos.

Além disso, os limiares utilizados para classificação de risco foram definidos como critérios operacionais, uma vez que a literatura não estabelece valores universais para essas métricas. Estudos futuros podem buscar calibrar esses limites com base em amostras mais amplas, contribuindo para maior robustez e comparabilidade. Outra limitação refere-se à natureza quantitativa das métricas utilizadas, que não capturam integralmente aspectos qualitativos relevantes, como a governança do projeto, a criticidade das contribuições ou o contexto das interações entre os participantes. A incorporação dessas dimensões pode complementar a análise e oferecer uma visão mais completa do risco.

Por fim, destaca-se que os resultados estão condicionados ao conjunto de projetos e ao recorte temporal analisado, o que limita sua generalização. A aplicação do framework em outros contextos e ao longo do tempo pode contribuir para validar e refinar os achados apresentados. A análise dos projetos Kubernetes, React e Moby, com seus distintos modelos de governança e dinâmicas de contribuição, demonstrou a aplicabilidade do framework em cenários variados, oferecendo uma base sólida para futuras investigações e aprimoramentos metodológicos.

Em síntese, a aplicação do framework de avaliação de riscos revelou que a viabilidade da adoção de softwares de código aberto em contextos corporativos exige uma visão estruturada de governança, que vai além da análise puramente técnica ou de popularidade. Os resultados evidenciaram perfis distintos de maturidade entre os projetos, com o Kubernetes apresentando maior resiliência institucional, enquanto React e Moby revelaram riscos associados à concentração de conhecimento e dependência de grupos restritos de mantenedores. O modelo proposto atingiu o objetivo de converter dados operacionais complexos em uma matriz de apoio à decisão, permitindo que organizações fundamentem suas escolhas tecnológicas entre a adoção estratégica, o monitoramento ativo ou a contenção de componentes em ambientes de alta criticidade.

4. Conclusão

O presente estudo buscou propor um framework de avaliação de riscos para organizações que utilizam software de código aberto (OSS), fundamentado em indicadores quantitativos e voltado ao apoio à tomada de decisão, considerando as dimensões de continuidade, agilidade e sustentabilidade. Por meio de um estudo de caso múltiplo, que analisou os repositórios Kubernetes, React e Moby, verificou-se que os projetos apresentaram perfis de risco distintos. Observou-se que o Kubernetes demonstrou maior resiliência institucional e governança distribuída, com baixo risco em continuidade e sustentabilidade, mas alto risco na agilidade devido ao tempo de integração de contribuições. Em contraste, React e Moby revelaram riscos mais elevados, principalmente associados à concentração de conhecimento em poucos contribuidores e, no caso do Moby, à lenta capacidade de resposta da comunidade. O framework mostrou-se eficaz ao converter dados operacionais complexos em uma matriz de apoio à decisão, capacitando as organizações a fundamentar suas escolhas tecnológicas entre a adoção estratégica, o monitoramento ativo ou a mitigação de riscos em ambientes de alta criticidade.

Apesar da contribuição prática do framework, identificou-se limitações relacionadas à qualidade dos dados obtidos do GitHub, especialmente na ausência de informações sobre a afiliação organizacional de diversos contribuidores, o que pode comprometer a precisão de métricas como o Elephant Factor. Além disso, os limiares de classificação de risco foram definidos como critérios operacionais, dada a ausência de valores universais na literatura, e a natureza quantitativa das métricas não capturou aspectos qualitativos da governança e criticidade das contribuições. Sugere-se para estudos futuros o enriquecimento de dados por meio de fontes complementares ou técnicas de inferência para afiliação organizacional, a calibração dos limites de risco com amostras mais amplas e a incorporação de dimensões qualitativas para uma análise mais completa. A aplicação do framework em outros contextos e recortes temporais também pode validar e refinar os achados, consolidando a integração de múltiplas dimensões de risco como uma ferramenta robusta para a avaliação da sustentabilidade tecnológica.

Referências Bibliográficas

AVELINO, G. et al. 2019. A novel approach for estimating truck factors. ICSE, [S. I.].

CHAOSS. 2019. Community Health Analytics Open Source Software: project metrics. Disponível em: https://chaoss.community/metrics/. Acesso em: 23 mar. 2026.

FORSGREN, Nicole; HUMBLE, Jez; KIM, Gene. 2018. Accelerate: the science of lean software and devops: building and scaling high performing technology organizations. Portland: IT Revolution Press.

GIL, Antonio Carlos. 2002. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas.

GITHUB ARCHIVE. 2026. GitHub Archive. Disponível em: https://www.gharchive.org. Acesso em: 23 mar. 2026.

GITHUB, Inc. 2026. GitHub. Disponível em: https://github.com. Acesso em: 23 mar. 2026.

GITHUB. 2026. React License (MIT License). Disponível em: https://github.com/facebook/react/blob/main/LICENSE. Acesso em: 11 abr. 2026.

GOUSIOS, G.; PINZGER, M.; VAN DEURSEN, A. 2014. An exploratory study of the pull-based software development model. ICSE, [S. I.].

JIANG, J. et al. 2017. Will my project get noticed? Predicting pull request response. MSR, [S. I.].

KALLIAMVAKOU, E. et al. 2016. An in-depth study of the promises and perils of mining GitHub. MSR, [S. I.].

PINGCAP. 2026. OSS Insight. Disponível em: https://ossinsight.io. Acesso em: 23 mar. 2026.

REACT. 2026. React: official documentation. Disponível em: https://react.dev/. Acesso em: 11 abr. 2026.

REINERTSEN, Donald G. 2009. The principles of product development flow: second generation lean product development. Redondo Beach: Celeritas.

RICCA, Filippo et al. 2011. A study on the evolution of the truck factor in 133 open source projects. In: INTERNATIONAL CONFERENCE ON SOFTWARE MAINTENANCE (ICSM), 2011. Anais… [S. I.: s. n.].

SONATYPE. 2023. 9th annual state of the software supply chain. Fulton: Sonatype. Disponível em: https://www.sonatype.com/hubfs/SSC/2023%20Sonatype-%209th%20Annual%20State%20of%20the%20Software%20Supply%20Chain-%20Update.pdf. Acesso em: 15 abr. 2026.

STEINMACHER, I. et al. 2015. Barriers faced by newcomers to open source projects. CSCW, [S. I.].

SYNOPSYS. 2024. 2024 open source security and risk analysis (OSSRA) report. Synopsys Cybersecurity Research Center. Disponível em: https://static.carahsoft.com/concrete/files/1617/1597/8665/2024_Open_Source_Security_and_Risk_Analysis_Report_WRAPPED.pdf. Acesso em: 15 abr. 2026.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy