O que é Open Source e como o GitHub cresceu e ganhou dinheiro?

Open source não significa simplesmente tornar o código-fonte público. É uma forma de conceder a outras pessoas os direitos de usar, estudar, modificar e redistribuir software sob uma licença definida. O GitHub tornou-se uma plataforma comercial ao reunir esse tipo de desenvolvimento colaborativo em um único fluxo de trabalho para repositórios, controle de versão, revisão de código e automação.

O modelo de negócios central do GitHub não é vender diretamente projetos open source públicos. Ele atrai uma grande base de usuários gratuitos e cobra pela colaboração privada, pelos controles de acesso, pela segurança, pela conformidade, pela automação, pelos ambientes de desenvolvimento em nuvem e pelos recursos de inteligência artificial de que as empresas precisam.

Índice

• O significado preciso de open source
• O contexto por trás do movimento open source
• Como funciona o desenvolvimento open source
• As diferenças entre open source, Git e GitHub
• As origens e o crescimento do GitHub
• O modelo de receita do GitHub
• Por que open source gratuito cria valor econômico
• Limitações e critérios de avaliação

O que exatamente é Open Source?

Software open source é um software cujo titular dos direitos autorais concede aos usuários, por meio de uma licença, direitos que incluem executar, estudar, modificar e redistribuir o software. A questão principal não é apenas se o código pode ser visualizado, mas quais direitos são legalmente permitidos.

Segundo a definição da Open Source Initiative (OSI), uma licença open source deve permitir redistribuição livre, fornecer o código-fonte e permitir a distribuição de modificações e obras derivadas. Ela não pode discriminar nenhuma pessoa, grupo ou área de uso. Portanto, se forem aplicáveis restrições como “somente para uso não comercial” ou “não pode ser usado em produtos concorrentes”, é difícil reconhecer o software como open source no sentido usual, mesmo que seu código-fonte seja público. OSI의 Open Source Definition↗

Essa distinção é especialmente importante para repositórios públicos no GitHub. Mesmo que um repositório esteja visível publicamente para todos, a legislação padrão de direitos autorais se aplica se ele não tiver uma licença open source. Outras pessoas podem visualizar ou fazer fork do repositório dentro do serviço GitHub, mas não recebem automaticamente o direito de copiar, modificar e distribuir livremente o código. O GitHub também explica que uma licença que declare as permissões de uso é necessária para que um projeto seja realmente open source. GitHub의 저장소 라이선스 안내↗

As três afirmações a seguir, portanto, têm significados diferentes:

• “Você pode visualizar o código” descreve se o código-fonte é público.
• “Você pode usá-lo gratuitamente” descreve seu preço.
• “É open source” descreve os direitos concedidos por sua licença.

Software livre não é necessariamente open source, e software open source também pode ser vendido.

Que contexto levou ao movimento Open Source?

A prática de compartilhar código de software e aprimorá-lo colaborativamente já existia nas primeiras comunidades de pesquisa em computação. Contudo, à medida que o software se desenvolveu como um produto comercial independente e as restrições de direitos autorais e de uso se fortaleceram, também cresceu a preocupação com a capacidade dos usuários de estudar e corrigir software.

Na década de 1980, Richard Stallman lançou o Projeto GNU e o movimento do software livre. Em software livre, “livre” não se refere ao preço, mas à liberdade dos usuários de executar, estudar, modificar e redistribuir um programa, seja na forma original ou modificada. GNU의 자유 소프트웨어 정의↗

O nome “open source” foi criado em uma reunião estratégica realizada pouco depois de a Netscape anunciar planos de liberar o código-fonte de seu navegador em 1998. No mesmo ano, Eric Raymond, Bruce Perens e outros estabeleceram a OSI e organizaram a Open Source Definition com base nas Debian Free Software Guidelines. O objetivo era explicar mais claramente às empresas e ao público as vantagens práticas do desenvolvimento colaborativo. OSI 역사↗

Software livre e open source se sobrepõem em grande medida nas licenças que aceitam, mas diferem em sua ênfase.

Essa diferença não significa que um dos lados seja sempre superior. Significa que o mesmo programa pode ser explicado sob uma perspectiva ao focar nos direitos dos usuários e sob outra ao focar na eficiência do desenvolvimento transparente e da colaboração distribuída.

Como funciona o desenvolvimento Open Source?

Open source não significa que “qualquer pessoa pode alterar o código como quiser”. A participação pode ser aberta, mas os mantenedores do projeto e procedimentos estabelecidos determinam o que é incorporado a uma versão oficial.

Um processo típico de desenvolvimento funciona da seguinte maneira:

1. Um mantenedor publica o código-fonte, a licença, as instruções de uso e as regras de contribuição.
2. Um usuário clona ou faz fork do repositório para criar um espaço de trabalho independente.
3. Correções de bugs ou desenvolvimento de recursos são realizados em uma branch separada.
4. O colaborador envia um Pull Request com as alterações e sua justificativa.
5. Os mantenedores revisam o código, os resultados dos testes, a direção do design e o impacto de segurança.
6. Somente alterações que atendem aos critérios são mescladas ao repositório oficial.
7. Uma nova versão é lançada, e problemas descobertos posteriormente são rastreados novamente.

Há diferentes funções nesse processo. Usuários utilizam o software e relatam problemas. Colaboradores enviam código ou documentação. Mantenedores realizam revisões e lançamentos. Um comitê diretor ou fundação do projeto também pode administrar marcas registradas, orçamentos e regras de tomada de decisão.

Em outras palavras, a “abertura” de open source não significa que não exista autoridade decisória. As oportunidades de participação e os direitos de uso do código são abertos, enquanto projetos oficiais possuem estruturas de controle para manter a qualidade.

Como as licenças Open Source diferem?

As licenças open source podem ser entendidas, de modo geral, como licenças permissivas e licenças copyleft.

Licenças permissivas

MIT, BSD e Apache License 2.0 são exemplos comuns. Desde que condições como a manutenção dos avisos de direitos autorais e do texto da licença sejam atendidas, essas licenças geralmente permitem que código modificado seja incluído em software proprietário.

Isso facilita a integração por empresas em produtos comerciais, mas não há garantia de que o código aprimorado retornará à comunidade original. A Apache License 2.0 também inclui disposições explícitas relacionadas a patentes, portanto suas condições jurídicas não são idênticas às da licença MIT.

Licenças copyleft

A GNU General Public License (GPL) é um exemplo representativo. Quando código modificado é distribuído, ou quando uma obra derivada combinada com esse código é distribuída, ela pode exigir que o código-fonte seja fornecido sob a mesma licença.

Copyleft não proíbe o uso comercial. O software pode ser vendido comercialmente, mas as obrigações de divulgação do código-fonte dentro do escopo definido pela licença devem ser seguidas. Variantes como LGPL e AGPL foram projetadas com condições diferentes para vinculação de bibliotecas e serviços de rede.

Ao escolher uma licença, ela não deve ser selecionada apenas porque um projeto conhecido a utiliza. É necessário examinar o escopo de divulgação para obras derivadas, as disposições sobre patentes, a oferta por serviços de rede e a compatibilidade com outras licenças.

Qual é a diferença entre Open Source, Git e GitHub?

Esses três conceitos costumam aparecer juntos, mas operam em camadas diferentes.

• Open source é um conceito que descreve os direitos de uso de software e um método de desenvolvimento colaborativo.
• Git é um programa open source de controle de versão que gerencia de forma distribuída o histórico de alterações de arquivos.
• GitHub é um serviço comercial que hospeda repositórios Git online e fornece recursos de revisão de código, gestão de issues, automação, segurança e colaboração.

O Git foi criado em 2005 depois que a relação entre a comunidade de desenvolvimento do kernel Linux e a ferramenta proprietária de controle de versão distribuído BitKeeper terminou. Era necessária uma ferramenta que pudesse lidar com a velocidade, o trabalho distribuído e o grande número de branches paralelas exigidos por um projeto tão grande quanto o Linux. Git 공식 역사↗

Com o Git, cada desenvolvedor pode manter um repositório com o histórico completo de alterações sem estar sempre conectado a um servidor central. No entanto, o Git de linha de comando, por si só, tornava inconveniente gerenciar quem propôs uma alteração, por que ela era necessária, quem a revisaria e quando seria mesclada. O GitHub organizou precisamente esse processo colaborativo por meio de uma interface web.

O Git pode ser usado sem o GitHub, e repositórios podem ser executados no GitLab, Bitbucket ou em servidores auto-hospedados. Por outro lado, o GitHub contém não apenas open source, mas também código corporativo privado e código público sem licença. GitHub e open source não são sinônimos.

Como o GitHub começou?

O GitHub foi desenvolvido em torno de Tom Preston-Werner, Chris Wanstrath e PJ Hyett e lançado como serviço público em 2008. Scott Chacon, especialista em Git que mais tarde ficou conhecido como autor de Pro Git, também integrou a equipe inicial.

O primeiro commit no repositório interno do GitHub foi feito em outubro de 2007, e o serviço foi lançado em abril de 2008. Por volta de seu primeiro aniversário, o GitHub tinha mais de 20.000 repositórios públicos e quatro funcionários em tempo integral, sem ter recebido investimento externo. GitHub의 첫해 기록↗

O problema que o GitHub buscava resolver não era apenas o armazenamento de arquivos. Ele procurava criar um ambiente colaborativo que visualizasse alterações em repositórios Git distribuídos, ajudasse desenvolvedores a descobrir o trabalho uns dos outros e facilitasse a revisão de propostas de mudança. O grafo de rede lançado pelo GitHub em 2008 também foi uma tentativa de mostrar, em uma única tela, as relações entre branches e commits de vários usuários. 초기 Network Graph 소개↗

Essa abordagem mais tarde passou a ser chamada de “social coding”. Perfis de desenvolvedores, históricos de atividade, follows, forks, stars, issues e pull requests passaram a estar conectados aos repositórios de código, transformando o próprio processo de desenvolvimento em uma rede que podia ser pesquisada e observada.

Por que o GitHub cresceu tão rapidamente?

O crescimento do GitHub não pode ser explicado apenas por oferecer armazenamento Git gratuito. Momento técnico, experiência do usuário, efeitos de rede e um modelo de negócios empresarial trabalharam em conjunto.

Tornou compreensível na web o complexo processo de colaboração do Git

Branches, commits e merges são recursos poderosos do Git, mas não são fáceis de entender para iniciantes apenas por comandos. O GitHub reuniu diferenças de código, discussões, resultados de revisão e status de testes na interface de pull request.

Em vez de circular arquivos de patch por e-mail, desenvolvedores podiam compartilhar alterações por meio de um único link. Mantenedores de projetos podiam reduzir os custos de revisão porque o código e o processo de discussão ficavam registrados juntos.

Repositórios públicos criaram uma rede de desenvolvedores

Quando um projeto entra no GitHub, os usuários e colaboradores desse projeto também têm maior probabilidade de criar contas. Esses usuários então criam outros projetos ou participam dos existentes.

À medida que o número de repositórios aumenta, desenvolvedores visitam o GitHub para encontrar código. À medida que o número de desenvolvedores aumenta, mantenedores escolhem o GitHub para atrair colaboradores. Trata-se de um efeito de rede de dois lados.

Históricos públicos de atividade também funcionavam como portfólios de desenvolvedores. Empresas podiam avaliar o código real e a experiência de colaboração dos candidatos, enquanto desenvolvedores tinham incentivo para construir históricos de atividade visando oportunidades de emprego e reputação.

Cresceu open source e produtos empresariais ao mesmo tempo

O GitHub reduziu a barreira de entrada para repositórios open source públicos e, desde seus primeiros dias, cobrava por repositórios privados. Em 2011, lançou o GitHub Enterprise, que podia ser executado em servidores internos de empresas e atendia necessidades empresariais como autenticação, backups e gestão de equipes. GitHub Enterprise 출시 기록↗

Essa estrutura permitiu que desenvolvedores individuais aprendessem a usar o GitHub em projetos open source e, depois, utilizassem uma versão empresarial do mesmo fluxo de trabalho ao entrar em uma empresa. Ela possibilitou uma adoção de baixo para cima, em que desenvolvedores levavam o produto para suas organizações sem esforços de vendas separados voltados a indivíduos.

O GitHub declarou ter alcançado lucratividade e crescimento por meio de serviços pagos sem investimento externo e recebeu seu primeiro investimento externo em 2012. GitHub의 2012년 투자 발표↗

Expandiu o plano gratuito e reduziu motivos para migrar para serviços concorrentes

Em 2019, o GitHub passou a oferecer repositórios privados para contas pessoais gratuitas. Em 2020, também removeu os limites de colaboradores para repositórios privados gratuitos e tornou gratuitos recursos centrais de equipe. Recursos avançados de gestão de permissões, segurança e suporte de que empresas precisam continuaram sendo ofertas pagas. GitHub Free 확대 발표↗

Expandir o plano gratuito significa abrir mão de parte da receita de assinaturas no curto prazo. Porém, isso mantém mais indivíduos e equipes pequenas na plataforma e cria oportunidades de convertê-los em clientes de produtos Team, Enterprise, segurança e IA à medida que suas organizações crescem.

Como a aquisição pela Microsoft afetou o crescimento do GitHub?

A Microsoft concordou em adquirir o GitHub em 2018 por US$ 7,5 bilhões em ações da Microsoft. Na época, o GitHub informou ter mais de 28 milhões de usuários. A Microsoft declarou que o GitHub manteria operações independentes e seu caráter voltado primeiro aos desenvolvedores. Microsoft의 GitHub 인수 발표↗

A aquisição alinhou necessidades estratégicas de ambos os lados. O GitHub poderia utilizar infraestrutura global de nuvem, uma rede de vendas empresariais e recursos de segurança e conformidade. A Microsoft poderia superar sua imagem anterior de empresa centrada no Windows e em software proprietário e estabelecer pontos de contato com desenvolvedores independentemente de sistema operacional ou linguagem de programação. Ela também ganhou oportunidades para conectar Azure, Visual Studio, VS Code e GitHub.

Após a aquisição, o GitHub expandiu-se além da hospedagem de repositórios para uma plataforma que cobre todo o ciclo de vida de desenvolvimento. O GitHub Actions automatiza builds, testes e implantações; o Codespaces fornece ambientes de desenvolvimento em nuvem; os produtos Advanced Security analisam código, dependências e segredos; e o Copilot oferece recursos de escrita e revisão de código com IA.

Em outubro de 2022, a Microsoft anunciou que o GitHub havia alcançado US$ 1 bilhão em receita recorrente anual (ARR) e crescido para mais de 90 milhões de usuários, três vezes o número existente na aquisição. Microsoft FY2023 1분기 실적 발표↗

O GitHub anunciou que mais de 100 milhões de desenvolvedores usaram a plataforma em 2023 e mais de 180 milhões em 2025. Em 2025, o total de projetos chegou a 630 milhões, e o GitHub contabilizou cerca de 81,5% de todas as contribuições como ocorrendo em repositórios privados. Isso mostra que o GitHub se tornou tanto um espaço open source quanto uma infraestrutura de desenvolvimento empresarial em grande escala. GitHub Octoverse 2025↗

Contudo, esses números são métricas de plataforma contabilizadas conforme os próprios critérios do GitHub. O número de desenvolvedores registrados não deve ser interpretado como equivalente ao de usuários ativos mensais ou clientes pagantes. A Microsoft também não divulga todos os anos em detalhes a receita e o lucro operacional atuais do GitHub como unidade de negócio independente; portanto, o ARR de US$ 1 bilhão informado em 2022 deve ser visto como uma métrica representativa de escala divulgada naquele momento, não como receita atual.

Especificamente, de onde vem o dinheiro do GitHub?

O modelo de receita do GitHub pode ser resumido como freemium: ele adquire usuários por meio de uma plataforma pública gratuita e cobra pelo controle e pela produtividade de que organizações precisam para operar.

Assinaturas por licença de usuário

O plano gratuito permite que indivíduos e equipes pequenas usem recursos centrais de repositório. O plano Team oferece recursos avançados de colaboração, enquanto o plano Enterprise oferece segurança, conformidade, administração centralizada e opções de implantação.

De acordo com a página oficial de preços consultada em setembro de 2026, o Team começa em US$4 por usuário por mês e o Enterprise começa em US$ 21 por usuário por mês. Os valores reais podem variar conforme prazo do contrato, região, impostos e condições de contratos grandes. GitHub 공식 가격표↗

A cobrança baseada em licenças tem a vantagem de que a receita recorrente pode crescer à medida que o quadro de funcionários de uma empresa aumenta. Quando código e processos de trabalho se estabelecem na plataforma, os custos de troca também aumentam, tornando mais provável a retenção dos contratos.

Assinaturas de produtos de IA e cobrança baseada em uso

O GitHub Copilot tem planos pagos para indivíduos e organizações. Empresas compram licenças para cada usuário, e cobranças adicionais por uso podem ser aplicadas quando o uso de IA incluído em um plano é excedido. Portanto, o Copilot está se desenvolvendo como um modelo que combina assinaturas tradicionais de software com cobrança pelo uso de computação de IA. GitHub Copilot 조직 청구 안내↗

O Copilot não apenas adiciona uma nova fonte de receita ao GitHub, como também faz com que a IA seja consumida dentro de fluxos de trabalho estabelecidos envolvendo repositórios, issues, pull requests e revisão de código. Isso torna mais fácil vender produtos adicionais a clientes existentes da plataforma do que seria vender uma ferramenta de IA separada.

Produtos de segurança e conformidade

Grandes empresas não pagam apenas por um local para armazenar código. Elas precisam de controles de conta, logs de auditoria, logon único, detecção de segredos, análise de vulnerabilidades no código, gestão da cadeia de suprimentos e conformidade regulatória.

À medida que cresce a dependência de componentes open source, as organizações precisam verificar continuamente pacotes vulneráveis e credenciais vazadas. A expansão do ecossistema gratuito, paradoxalmente, também aumenta a necessidade de produtos de segurança empresariais.

Uso de computação, armazenamento e automação

Serviços como GitHub Actions, Codespaces e Packages incluem determinada quantidade de uso em um plano e cobram pelos excedentes. A fatura de uma empresa pode incluir não apenas licenças Enterprise, mas também uso excedente de Actions ou Codespaces e licenças adicionais para produtos como Copilot e ferramentas de segurança. GitHub Enterprise 청구 구조↗

Esse modelo permite que a receita do GitHub cresça conforme a atividade de desenvolvimento aumenta. Por outro lado, o GitHub também arca com os custos de servidores de execução, dispositivos de armazenamento, redes e modelos de IA; portanto, nem toda receita de uso é lucro.

Taxas de transação do Marketplace

Desenvolvedores terceiros podem vender apps pagos pelo GitHub Marketplace. O GitHub fornece gestão de pagamentos e assinaturas e retém uma parte do valor das transações como taxa operacional. Segundo a documentação oficial, a parcela retida aplicada às transações de apps desde 2021 é de 5%. GitHub Marketplace 판매 대금 안내↗

Além das taxas diretas do Marketplace, também é importante que ferramentas externas passem a ter o GitHub como centro. À medida que mais apps são usados, mais ferramentas de desenvolvimento precisam ser substituídas ao sair do GitHub, fortalecendo a capacidade de retenção da plataforma.

Por que Open Source gratuito tem valor econômico para o GitHub?

Para o GitHub, repositórios públicos gratuitos não são apenas um item de custo. Eles são um ativo central para aquisição de usuários e formação de ecossistema.

Primeiro, projetos open source atraem novos usuários. Desenvolvedores que querem usar uma biblioteca específica, relatar um problema ou enviar um patch criam contas no GitHub. O GitHub pode adquirir esses usuários sem gastar com publicidade.

Segundo, a atividade open source torna a forma de trabalhar do GitHub um padrão de fato do setor. Desenvolvedores aprendem sobre forks, issues e pull requests na escola ou em projetos pessoais e depois preferem a mesma abordagem no trabalho.

Terceiro, o ecossistema público e o desenvolvimento empresarial privado dependem um do outro. Produtos privados de empresas também usam inúmeras bibliotecas e ferramentas públicas. Nos dados do GitHub de 2025, a maior parte da atividade de contribuição ocorreu em repositórios privados, enquanto os projetos públicos representaram a maioria em número de repositórios. O ecossistema público gratuito fornece a base para o trabalho empresarial pago.

Quarto, projetos públicos mais ativos aumentam a demanda por segurança e automação. Atualizações de dependências, detecção de pacotes maliciosos, gestão de licenças e testes e implantações em larga escala tornam-se necessários.

O apoio do GitHub a open source gratuito é, portanto, difícil de explicar apenas como filantropia ou apenas como atividade comercial. Ele oferece valor genuíno à comunidade de desenvolvedores e, ao mesmo tempo, serve como uma estratégia de distribuição de longo prazo que leva ao mercado empresarial pago.

Como empresas Open Source geralmente ganham dinheiro?

O modelo de negócios do GitHub é um entre vários modelos de receita que utilizam open source. Empresas open source costumam cobrar não pelo código reproduzível em si, mas pela conveniência operacional, responsabilização, segurança e especialização.

• Suporte e consultoria: fornecem software gratuitamente e cobram pela instalação, resposta a incidentes, treinamento e suporte de longo prazo.
• Nuvem gerenciada: além do open source que os clientes podem instalar por conta própria, vendem SaaS que o opera em nome do cliente.
• Open core: tornam os recursos centrais públicos, enquanto oferecem recursos empresariais de gestão, segurança e análise sob licenças proprietárias.
• Licenciamento duplo: oferecem o mesmo código sob uma licença open source e uma licença comercial, permitindo que usuários escolham conforme suas circunstâncias.
• Hospedagem e uso: cobram com base no uso de armazenamento, rede, computação e execução de automação.
• Patrocínios e doações: indivíduos, empresas e fundações apoiam mantenedores ou a operação de projetos.
• Certificação e treinamento: obtêm receita por meio de treinamento oficial, exames, certificações técnicas ou programas de parceiros.

Esses modelos funcionam porque os custos de software não se limitam ao preço da licença. As empresas consideram o custo total de propriedade, incluindo tempo de instalação, risco de indisponibilidade, incidentes de segurança, atualizações, conformidade regulatória e escassez de profissionais especializados. Mesmo que consigam obter o código gratuitamente, podem estar dispostas a pagar por responsabilização operacional confiável.

Quais são as limitações de Open Source e GitHub?

Open source não se torna automaticamente software seguro e sustentável apenas porque tem muitos participantes.

A carga de manutenção pode se concentrar em poucas pessoas

Mesmo uma biblioteca amplamente utilizada pode depender de apenas alguns mantenedores para as revisões e os lançamentos efetivos. À medida que o uso cresce, aumenta a carga de relatos de issues e resposta a segurança, enquanto a remuneração dos mantenedores pode não crescer na mesma proporção.

Revisão pública não garante qualidade

O fato de o código-fonte ser público é diferente de alguém tê-lo revisado suficientemente. Os riscos da cadeia de suprimentos incluem vulnerabilidades, contribuições maliciosas, contas de mantenedores comprometidas e dependências contaminadas.

Obrigações de licença podem ser ignoradas

Open source não é um bem público sem direitos autorais. As condições de cada licença devem ser cumpridas, incluindo manter avisos de direitos autorais, fornecer o código-fonte, indicar alterações e aplicar a mesma licença. A compatibilidade de licenças deve ser revisada especialmente em produtos comerciais que combinam muitas dependências.

A concentração na plataforma cria novas dependências

Como o Git é distribuído, repositórios podem ser movidos para outros servidores. No entanto, migrar integralmente issues, discussões de pull requests, fluxos de trabalho do Actions, políticas de acesso, apps do Marketplace e registros de segurança é muito mais difícil.

Quanto mais conveniente o GitHub se torna, mais as comunidades de desenvolvimento podem depender dos preços, políticas, resposta a incidentes e mudanças de recursos de uma única empresa. É necessário clonar o código localmente, fazer backup de lançamentos e documentação e entender as dependências de recursos específicos da plataforma.

Quais são os equívocos comuns?

“É público no GitHub, então é open source”

Sem uma licença, os direitos de uso comuns de open source não surgem. Visibilidade e licenciamento são configurações separadas.

“Todo open source é gratuito”

Pode não haver custo de cópia, mas operações, suporte, serviços de nuvem, treinamento e recursos de segurança podem ter custos. Licenças open source não proíbem vendas pagas.

“Qualquer pessoa pode alterar o código oficial como quiser”

O direito de qualquer pessoa modificar sua própria cópia é diferente da autoridade para incorporar alterações ao projeto oficial. Mantenedores e regras de governança decidem se as alterações são incluídas oficialmente.

“O próprio GitHub é open source”

O GitHub hospeda projetos open source em escala e lança diversas ferramentas open source, mas todo o serviço GitHub não é um único produto open source. O GitHub é uma plataforma comercial pertencente à Microsoft.

“Como o GitHub tem muitos usuários, a maioria deles é pagante”

As contagens de desenvolvedores informadas pelo GitHub incluem contas gratuitas. Total de desenvolvedores registrados, desenvolvedores ativos, clientes empresariais e licenças pagas são métricas diferentes.

“A Microsoft opera o GitHub gratuitamente”

Embora repositórios gratuitos estejam amplamente disponíveis, o GitHub gera receita com licenças empresariais, IA, segurança, automação, computação, armazenamento e o Marketplace. Usuários gratuitos fornecem tanto potencial de conversão para clientes pagantes quanto valor de rede.

Como avaliar um projeto Open Source?

Ao adotar open source em um projeto real, não observe apenas a contagem de stars ou os rankings do GitHub. Analise em conjunto os itens a seguir:

• O arquivo LICENSE e a compatibilidade jurídica com o uso pretendido
• A frequência de lançamentos recentes e atualizações de segurança
• O número de mantenedores principais e a dependência de indivíduos específicos
• A velocidade de revisão de issues e pull requests
• A existência de procedimentos para testes, automação e relatos de vulnerabilidades
• A integridade da documentação e das orientações de atualização
• A equipe e os custos necessários para auto-hospedagem
• A dependência do GitHub ou de um serviço de nuvem específico
• Alternativas disponíveis e viabilidade de migração caso o projeto seja descontinuado

Os mesmos princípios se aplicam ao selecionar o GitHub como plataforma de trabalho. Em vez de comparar apenas preços gratuitos, avalie em conjunto a gestão de permissões necessária, auditoria, segurança, uso de automação, uso de IA, localização dos dados, resposta a incidentes e custos de migração.

Como deve ser entendida a relação entre Open Source e GitHub?

Open source é um conjunto de regras que distribui direitos para usar e aprimorar software de forma colaborativa. Git é uma ferramenta para gerenciar de modo distribuído o histórico dessas alterações, e GitHub é uma plataforma que intermedeia a colaboração baseada em Git em escala.

O GitHub não inventou o open source. Em vez disso, simplificou em um fluxo de trabalho web unificado os processos de descoberta, cópia, discussão, revisão e merge de que comunidades open source precisam. Projetos públicos criaram uma rede de desenvolvedores, e essa rede também atraiu o desenvolvimento empresarial privado para o GitHub.

Como resultado, em vez de cobrar entrada para código público, o GitHub construiu um modelo que cobra pelo controle, segurança, automação, computação e IA de que empresas precisam para colaborar em escala. Ele começou com um modelo inicial de “público é gratuito e privado é pago”, mas hoje pode ser entendido como um negócio de plataforma de desenvolvimento em que “a colaboração básica é gratuita e os recursos que resolvem a complexidade organizacional são pagos”.