O financiamento de projetos de código aberto poderia manter o desenvolvimento em andamento, mas esse financiamento seria levantado e quem pagaria por ele?

Você trabalharia de graça? É uma questão simples, mas carregada que requer contexto adicional. É trabalhar para ajudar um amigo a fazer algo? É um trabalho que você gostaria? O ato de trabalhar de graça lhe dá algum nível de satisfação? Sua reação instintiva à pergunta pode ter sido um caloroso “Não”, mas muitas pessoas se voluntariam para uma variedade de coisas o tempo todo, então as pessoas trabalharão de graça quando houver algo de que gostem.

O desenvolvimento de código aberto pode ser visto como uma forma de voluntariado. Muitos desenvolvedores doaram seu tempo para manter ou contribuir com projetos de código aberto. Esses desenvolvedores podem não se importar em serem compensados ​​por seu tempo - eles estão apenas felizes pela experiência, pelo desafio ou podem apenas gostar de ajudar os outros.

Os desenvolvedores que fazem isso por nada mais do que um tapinha nas costas são ótimos, no entanto, pode ser difícil contar com o ecossistema de código aberto em geral. Compromissos de tempo são provavelmente o maior problema em jogo aqui, já que os desenvolvedores costumam trabalhar nesses projetos em seu tempo livre. Entre trabalhar, dormir e sair com amigos e familiares, pode ser difícil ter um fluxo constante de compromisso voluntário com um projeto. Este problema é ampliado dependendo do próprio projeto e dos conjuntos de habilidades necessários para fazer contribuições grandes e significativas.

Financiar projetos de código aberto é uma maneira de tentar resolver isso. Em vez de os desenvolvedores trabalharem com código aberto em seu tempo livre, eles podem ser financeiramente compensados ​​por isso como parte de seu dia de trabalho normal. O problema de pagar pelas contribuições de um desenvolvedor para projetos de código aberto é como esse financiamento é levantado e quem paga por ele.

As doações são comumente usadas como um meio básico para arrecadar fundos - sejam patrocinadores do GitHub , Open Collective ou Buy Me A Coffee , etc. Embora as doações sejam muito apreciadas por aqueles que as recebem, elas dependem da boa vontade de outros e podem ser apenas uma fonte sustentável de financiamento para projetos extremamente populares. Isso deixa a grande maioria dos projetos sem financiamento adequado, embora possam não ser menos dignos dele.

Se o financiamento de código aberto não puder depender de doações, será necessário cobrar algum tipo de taxa em algum momento do processo. Mas, você diz, o código aberto não deveria ser gratuito? Código aberto não é sobre software livre, é sobre liberdade de software. Conforme descrito pela Open Source Initiative (OSI)

O código aberto permite um método de desenvolvimento de software que aproveita o poder da revisão por pares distribuída e a transparência do processo. A promessa do código aberto é maior qualidade, melhor confiabilidade, maior flexibilidade, menor custo e o fim do aprisionamento predatório de fornecedores.

Então, o que exatamente impede os desenvolvedores de código aberto de cobrar por seu trabalho?

Problemas potenciais de licenciamento

Pode não haver nada tão divisivo ao falar sobre código aberto quanto discutir o licenciamento de projetos. Existem licenças que restringem como um projeto é usado ou quem o usa, e outras sem nenhuma restrição. Dependendo com quem você fala, a menção de uma licença copyleft como a GPL é suficiente para fazer alguns desenvolvedores rodarem para projetos alternativos sob uma licença mais permissiva como a licença MIT.

Algumas dessas restrições nessas licenças podem parecer opostas à abertura e à liberdade que a definição de código aberto do OSI proclama. Pode ser melhor pensar nesses projetos como "desenvolvidos abertamente" do que em uma definição estrita de código aberto. Esses tipos de projetos também merecem financiamento, sejam eles estritamente de código aberto ou não. É com o licenciamento, porém, que esses projetos podem ser ainda mais impactados na busca por financiamento.

Ter financiamento para um projeto de código aberto exige que as pessoas conheçam e usem o projeto. Os desenvolvedores que desejam usar o projeto precisam concordar com a licença e, a menos que eles trabalhem como especialistas jurídicos, pode ser difícil entender as ramificações legais das licenças. Isso é o que torna as licenças mais novas e restritivas menos prováveis ​​de serem aceitas - nem todas as licenças que um desenvolvedor encontra podem ser executadas por um advogado para garantir a conformidade.

É, no entanto, nessas configurações de licenças mais complexas que os desenvolvedores de código aberto costumam tentar cobrar por seu trabalho. Por exemplo, ter uma licença dupla do MIT para fins não comerciais e uma licença personalizada para fins comerciais. Os desenvolvedores podem ter uma boa compreensão da licença permissiva do MIT, entretanto, podem precisar evitar o mesmo projeto em seu local de trabalho devido à estipulação de licenciamento comercial. Esta é uma distinção importante quando se considera quem financiaria o desenvolvimento de código aberto.

As fontes de financiamento

Ao procurar financiamento, considere os diferentes grupos que podem estar consumindo seu projeto de código aberto. Você tem outros desenvolvedores também fazendo trabalho de código aberto, trabalho de código fechado não comercial, como o que pode ser um hobby ou projeto paralelo, e projetos comerciais que podem ser de código aberto ou não. Cada um desses grupos tem prioridades e expectativas diferentes.

Outros desenvolvedores com seus próprios projetos de código aberto podem parecer bons candidatos - eles entendem e apreciam o trabalho de código aberto e o tempo e esforço envolvidos. O problema aqui é que esses desenvolvedores provavelmente estariam usando muito mais projetos do que podem financiar razoavelmente. Também existe a preocupação de que este seja efetivamente um ecossistema fechado onde os desenvolvedores estão pagando outros desenvolvedores que estão pagando outros desenvolvedores. Isso cria um ciclo em que não só não há dinheiro adicional para a troca de mãos, mas o dinheiro que está sendo compartilhado diminui lentamente por meio de coisas como taxas de processamento. Esta não é uma solução viável para o problema de financiamento.

Como os desenvolvedores que podem usar o projeto em seu próprio trabalho de código aberto, aqueles que têm hobby de código fechado ou projetos paralelos que dependem de você provavelmente pertencem ao mesmo grupo de desenvolvedores que também trabalham com código aberto. Este é novamente o ciclo de desenvolvedores pagando desenvolvedores sem nenhum investimento de capital real sendo adicionado ao ecossistema de código aberto. Pode ser melhor do que nada, mas não é uma estratégia viável a longo prazo.

O uso comercial, por outro lado, é uma boa fonte potencial de novo capital para o ecossistema. As empresas que usam código aberto provavelmente estão ganhando alguma vantagem ao usar seu projeto em comparação com outra solução, potencialmente tornando-as mais eficientes ou sendo capazes de fornecer serviços específicos para seus próprios clientes. As empresas já pagam por vários softwares, então um custo extra pode não parecer grande coisa. Infelizmente, mas de forma previsível, as empresas gostariam de manter seu dinheiro, portanto, a menos que o caso seja convincente, elas podem optar por soluções gratuitas.

A proposta de valor para empresas

Para simplificar, por que uma empresa iria querer financiar seu projeto? As empresas em geral não gravitam em torno da ideia de “fazer a coisa certa” só por fazer. As empresas, entretanto, podem financiar algo se conseguirem algo desejável em troca. Idealmente, então, uma empresa precisa ser encorajada a usar o que você construiu, mas ainda quer um pouco mais do negócio.

Talvez seja a segurança, não no sentido técnico, mas a tranquilidade de que o projeto de código aberto não irá desaparecer na próxima semana. Claro, o código-fonte ainda pode estar disponível, mas a menos que eles tenham habilidade técnica para construí-lo e mantê-lo por conta própria, a segurança adicional que o financiamento do projeto pode fornecer pode ser suficiente. Em outros casos, pode ser para garantir que os bugs no projeto sejam resolvidos com uma prioridade mais alta ou que recursos especiais sejam criados para ajudar a empresa.

Devido à natureza de longo prazo dessas razões para financiar um projeto, o tipo de financiamento mais apropriado aqui é um pagamento recorrente para ajudar a manter o projeto. Você não gostaria de ter um pagamento único e ficar no gancho para manutenção pelos próximos 10+ anos, você gostaria de algo para sustentar o projeto por toda a vida do projeto.

Porém, para que as empresas adotem essas abordagens, elas precisam estabelecer que os custos com o financiamento do projeto compensam os riscos de não financiá-lo. Os riscos, no entanto, dependem muito de como o projeto de código aberto está sendo usado e por quanto tempo pode ser usado. No curto prazo, podem ser empresas com novos projetos integrando seu projeto como um componente crítico. No longo prazo, podem ser empresas com projetos legados frágeis que precisam de suporte para versões mais antigas do seu projeto. Se seu projeto quebrou ou não funcionou da maneira que eles precisavam, isso poderia custar-lhes uma grande quantia se todo o sistema falhar. Nesses casos, o financiamento do seu projeto pode reduzir seus riscos, ajudando a sua continuidade de negócios.

Embora isso possa parecer direto ou lógico, não é tão simples. Mesmo projetos extremamente importantes que lidam com segurança e criptografia podem receber financiamento mínimo. Há uma ótima postagem de Aaron Stannard sobre a sustentabilidade de projetos de código aberto com um estudo de caso sobre OpenSSL.

Antes da vulnerabilidade “Heartbleed” , o OpenSSL recebia cerca de US $ 2.000 por ano em doações - não muito para algo que é usado tão amplamente. Após a vulnerabilidade, eles receberam cerca de US $ 9 mil em doações. Embora seja difícil colocar um custo total para a vulnerabilidade, foi estimado em US $ 500 milhões - imagine o projeto até mesmo recebendo uma fração disso em financiamento antes do anúncio da vulnerabilidade.

Em vez de financiar o projeto diretamente, algumas empresas podem ter seus próprios desenvolvedores contribuindo com código de volta para o projeto. Superficialmente, isso é ótimo, pois ter colaboradores adicionais pode tirar muito trabalho do mantenedor. Mesmo isso tem problemas, pois os objetivos deles e os seus podem não estar alinhados. Eles podem contribuir com novos recursos que você precisa para oferecer suporte ou correções de bugs que interrompem outros fluxos de trabalho, mudando a forma como você gasta seu tempo no projeto. Em vez de escrever qualquer código sozinho, você pode apenas executar testes, revisar solicitações de pull e validar problemas. Isso ainda pode colocá-lo à frente no tempo; Contudo; pode não ser o que você deseja gastar seu tempo. Embora eu não queira desencorajar as empresas a contribuir com solicitações pull relevantes e de alta qualidade, é estar atento ao que é melhor para o projeto, e não assumir o controle.

Se a proposta de valor não estiver lá para a empresa, ou o suporte que ela está fornecendo está mais atrapalhando do que ajudando, você pode ter que dar um passo além de ser um mantenedor de código aberto. Você pode precisar criar uma empresa em torno de seu projeto.

Transformando projetos em produtos

Os projetos de código aberto geralmente têm um escopo muito restrito. Talvez você tenha construído um rastreador da web, um cliente de API, um conversor de formato de data, um widget de calendário, etc. Por si só, são difíceis de comercializar e vender como uma empresa, e você pode ficar preso na mesma situação de financiamento que estava quando você começou. Em vez disso, você pode tentar reembalar o projeto em um produto maior que seja comercializável.

Se você construiu um rastreador da web, talvez esteja construindo um serviço da web para rastrear sites automaticamente com uma API simples. Se você construiu um conversor de formato de data, talvez um serviço que faça detecção de linguagem e formatação em strings e páginas da web. Diferentes projetos têm diferentes produtos potenciais e modelos de negócios que podem ser moldados em torno deles e, embora nem todos os projetos possam fazer isso facilmente, aqueles que podem encontrar clientes para este novo produto encontraram uma maneira de ajudar a financiar seu desenvolvimento de código aberto.

Projetos do GitLab para o re: dash funcionaram dessa maneira, pegando um projeto e colocando uma versão do produto nele. Ambos os exemplos usaram um modelo de assinatura para gerar receita para seu projeto, permitindo que eles se concentrassem em seu trabalho e aumentassem suas equipes. Isso, por sua vez, permitiu que mais recursos fossem adicionados rapidamente e que os bugs fossem corrigidos mais rapidamente.

Começar uma empresa para continuar sustentando projetos de código aberto é uma grande tarefa. Tirar a empresa do papel pode ser um processo extremamente demorado, exigindo que você se familiarize com a contabilidade comercial e outros trabalhos jurídicos, antes mesmo de voltar a manter o código em si.

Tudo isso é mais fácil dizer do que fazer e ignora a verdadeira natureza de querer financiamento para esses projetos. Diferentes desenvolvedores colocaram seu coração em seus projetos, dedicando grande quantidade de tempo e esforço para criar soluções e compartilhá-las com o mundo. Embora o código possa permanecer online em algum lugar para sempre, um projeto de código aberto só sobrevive verdadeiramente se alguém o mantiver.

O lado humano do código aberto

Para obter uma compreensão mais completa dos problemas de financiamento de código aberto, é importante ver várias perspectivas de outras pessoas na comunidade. Há duas pessoas que acompanho há um tempo que dedicaram muito tempo e esforço a vários projetos de código aberto.

James South, criador do ImageSharp (uma biblioteca de processamento de imagens .NET), está tentando ter seus projetos financiados. Mesmo usando Open Collective, patrocínios do GitHub e tendo licenças de suporte comercial disponíveis , o projeto luta por financiamento. Eu perguntei a ele quais eram suas idéias e perspectivas sobre o financiamento de código aberto:

O lado do financiamento do código aberto é algo com o qual tenho lutado há muito tempo, experimentando anteriormente com modelos de licença menos permissivos (com efeito desastroso) e agora tentando financiar meu trabalho com licenças de suporte comercial. Talvez as pessoas olhem para o número de estrelas / downloads que um projeto tem e vejam isso como uma medida de sucesso financeiro para o qual não acham que precisam contribuir, ou talvez não apreciem o esforço envolvido ... Não sei . O que sei é que algo deve mudar. A situação atual é insustentável e extremamente prejudicial para os mantenedores.

Também pedi a Dave Glick, criador do Statiq (um gerador de conteúdo estático .NET) e do Discover.NET (um site para recursos da comunidade .NET), para compartilhar suas idéias sobre o financiamento de código aberto:

Na medida em que um mantenedor deseja financiamento (e considerando que o financiamento não é apropriado ou desejado por todos em todos os projetos), acho que a melhor coisa que nós, como comunidade, podemos fazer é aceitar que o status quo não está funcionando. Se usarmos isso como ponto de partida, a próxima pergunta será "o que posso fazer de diferente?" Existem licenças alternativas a serem consideradas. Existem plataformas como Tidelift, Sdkbin e outras tentando novos modelos de vendas. Quanto mais mantenedores começarem a olhar para fora dos mecanismos de financiamento de projetos historicamente aceitos e começarem a considerar e apoiar alternativas, mais cedo poderemos normalizar essas alternativas e, com sorte, elevar todo o ecossistema de software aberto desenvolvido.

Tornando o código aberto sustentável

O código aberto é fundamentalmente bom com a transparência e flexibilidade que traz; no entanto, à medida que nossa dependência dele aumenta, o investimento geral de volta no ecossistema não aumentou. Pode ser fácil dar como certo o tempo e o esforço que muitos desenvolvedores colocam em projetos de código aberto. No entanto, é com seu tempo e esforço que muitas vezes salvamos o nosso.

Esses desenvolvedores não são gananciosos ou egoístas por quererem financiamento para seus projetos. Ao contrário, eles querem financiamento para manter o projeto vivo. Afinal, uma pessoa tem que comer. Financiar o projeto é um meio de mudar o timeshare do mantenedor - permitindo-se colocar tempo no projeto que de outra forma seria usado para outro emprego. Há muito tempo em um dia que uma pessoa pode dar.

O financiamento não deve ser uma luta para projetos de código aberto. Adotamos o código aberto em nossas bases de código com frequência, mas ainda temos que adotar totalmente a ideia de que financiá-lo realmente nos ajuda também. As correções de bugs e solicitações de recursos precisam ser implementadas, testadas e revisadas por alguém que não pode dedicar muito tempo ao projeto.

Embora tenha havido algum progresso recentemente com um anúncio do GitHub, mudando a forma como as empresas podem investir em projetos de código aberto, pode demorar um pouco para ver seu impacto no ecossistema de código aberto como um todo.

Infelizmente, não existe uma solução perfeita que resolva todos os problemas de financiamento do código aberto. Este post, mais do que qualquer outra coisa, é para chamar a atenção para a questão de que vários projetos nos quais dependemos fortemente podem precisar de ajuda. Comece verificando se o mantenedor do seu projeto favorito está procurando financiamento e veja como você pode ajudá-lo a levantá-lo. Talvez converse com seu chefe sobre como a sustentabilidade dos projetos de código aberto dos quais a empresa depende é um investimento útil para a empresa. É com essas pequenas ações, e outras, que talvez o financiamento de projetos de código aberto seja menos problemático no futuro.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.