Pagar mantenedores de open source é algo positivo
(jacobian.org)- O ecossistema de open source é algo de que muitas pessoas e empresas dependem, mas há uma contradição: quando mantenedores conseguem se sustentar por meio de recursos comerciais, emprego em grandes empresas ou captação de investimento, a primeira reação costuma ser crítica
- Aqui, open source é usado em um sentido mais amplo do que as definições estritas da OSI e da FSF, incluindo Polyform, JSON license e BSL quando se trata de código-fonte que pode ser lido, modificado e ter variações distribuídas
- Sustentabilidade não se refere apenas a governança ou à saúde da comunidade, mas a se mantenedores conseguem viver confortavelmente enquanto atendem a necessidades básicas como moradia, alimentação e saúde
- Django é usado diariamente por centenas de milhares de pessoas, mas há apenas 1 Fellow em tempo integral e 1 Fellow em meio período da DSF trabalhando de forma remunerada e dedicada no próprio Django; Python também é usado diariamente por milhões de pessoas, mas tem menos de 12 mantenedores remunerados
- Patreon, GitHub Sponsors, VC, Open Core e licenças não OSI têm falhas, mas quando a raiva é direcionada ao mantenedor individual, fica mais difícil ampliar o valor social do open source
Por que é bom que mantenedores sejam pagos
- O ponto de partida é a visão de que mantenedores de open source serem pagos não deve ser uma exceção, mas algo a ser celebrado
- Em vez de culpar mantenedores que encontraram uma forma de ganhar a vida, devemos criticar as estruturas e sistemas que tornam difícil receber por esse trabalho
- Quem quer viver de trabalho em open source deve poder atender às necessidades básicas e viver confortavelmente
- Open source é uma colaboração que beneficia todos, e a premissa é que um mundo sem open source seria muito pior do que o atual
Open source e sustentabilidade em sentido amplo
- Open source e free software são usados em sentido amplo, não nas definições estritas da OSI e da FSF
- Significa software cujo código-fonte pode ser lido, modificado e distribuído em versões derivadas
- Inclui não só licenças OSI e FSF, mas também Polyform licenses, JSON license e BSL
- Definições estreitas como “só licenças aprovadas pela OSI são open source” ou “só GPL é software livre de verdade” são vistas como parte do problema
- É preciso haver experimentação e diversidade em licenças, e a visão aqui é que algo pode entrar na categoria de open source mesmo com mais restrições do que “qualquer pessoa pode usar para qualquer finalidade”
- Sustentabilidade significa se mantenedores conseguem ter uma vida decente ou confortável escrevendo software livre
- O critério mínimo é atender a necessidades básicas como moradia, alimentação e saúde
- Idealmente, deveria ser possível até ter uma vida confortável ou luxuosa apenas com trabalho em open source
O open source atual não é sustentável
- O número de pessoas que ganham a vida apenas escrevendo software livre é, na prática, próximo de 0 entre todos os engenheiros de software
- Existem empresas que empregam pessoas para trabalhar em open source, como Canonical, Red Hat, Hashicorp e Mozilla, mas a escala é muito pequena em comparação com os milhões de engenheiros que escrevem software proprietário
- Nem todos os engenheiros dessas organizações escrevem apenas open source, e muitas delas dependem de modelos de negócio em que parte do produto é proprietária
-
Os números de Django e Python
- Centenas de milhares de engenheiros usam Django todos os dias
- As pessoas pagas para se dedicar ao próprio Django são 1 Fellow em tempo integral e 1 Fellow em meio período empregados pela DSF, ou seja, 1,5 pessoa
- Milhões de pessoas usam Python todos os dias, mas menos de 12 pessoas recebem dinheiro para trabalhar em Python
- Isso inclui os Developers-in-Residence da PSF e um pequeno número de mantenedores que lidam com Python como parte do trabalho em empresas como Google e Microsoft
- Em um estado sustentável, Django precisaria de cerca de 12 pessoas em tempo integral recebendo algo próximo à mediana do setor, e Python deveria ter dezenas de pessoas
- Só o PyPI, considerando seu escopo, escala e importância, precisaria de uma equipe de pelo menos 10 a 15 pessoas
- Mesmo em uma situação em que “uma pessoa aleatória em Nebraska” mantém sozinha uma dependência essencial, para que isso seja sustentável ela deveria ter colegas que lhe permitissem viver com folga e tirar férias
O ideal do apoio público e a lacuna atual
- O ideal seria que o software livre fosse reconhecido como um bem público e recebesse financiamento adequado da sociedade e dos governos
- Essa visão também pressupõe que problemas como saúde, acesso à moradia, transporte público e redes de proteção social precisam ser resolvidos em conjunto
- Mas essas mudanças não vão acontecer de imediato, e tampouco é certo que acontecerão durante nossa vida
- Dizer que “o governo deveria apoiar, portanto empresas privadas não deveriam dar dinheiro a mantenedores” acaba se reduzindo, enquanto o governo não apoia na prática, a “mantenedores não deveriam receber dinheiro”
- No mundo atual, é preciso reconhecer que mantenedores precisam ser pagos
Toda forma de receber dinheiro já é uma vitória
- Na realidade, sustentabilidade em open source significa que dinheiro de fato chega aos mantenedores
- Se um mantenedor encontrou uma forma de pagar o aluguel enquanto escreve software livre, isso por si só já é um caso positivo
- Há várias formas que podem ser vistas como casos positivos
- Ser empregado pela Microsoft para trabalhar em Python
- Receber subsídios
- Alcançar um nível sustentável de apoio no Patreon
- Captar investimento de VC para desenvolver software livre
- Criar um negócio sustentável com o modelo Open Core
- Trabalhar em uma empresa como a Hashicorp
- Apoiar um projeto aberto com uma opção de hospedagem paga
- Usar com sucesso uma licença não aprovada pela OSI para evitar exploração ao estilo Amazon
Críticas recorrentes e seus limites
- Sempre que um mantenedor recebe dinheiro, surgem críticas específicas ao modelo de financiamento
- Crítica de que licenças não OSI não são open source
- Crítica de que alguém empregado pela Microsoft está subordinado a interesses corporativos e não é confiável
- Crítica de que Patreon é mendicância
- Crítica de que GitHub Sponsors ajuda a busca de renda monopolista da Microsoft
- Crítica de que dinheiro de VC levará a rug pull ou enshittification
- Crítica de que Open Core é bait and switch
- Segundo o texto, um mantenedor chegou a ser criticado até por vender camisetas
- Cada modelo tem problemas reais
- Investimento de VC vem com condições e pode gerar problemas depois
- Patreon, GitHub e Stripe ficam com parte das doações
- As restrições adicionais de PolyForm ou BSL entram em conflito com o ideal da Freedom 0
- Pode ser frustrante quando uma funcionalidade central desejada em uma ferramenta Open Core existe apenas na licença paga
- Esses sistemas podem ser criticados, mas atacar o mantenedor individual que recebeu dinheiro é direcionar a raiva para o lugar errado
- É como gritar com alguém por fazer compras quando a única loja acessível é a Dollar General; o problema não está no indivíduo, mas nas estruturas e políticas
Exigências de pureza limitam o valor social do open source
- Muito mais pessoas deveriam escrever software livre e receber dinheiro por isso
- Para isso, é preciso aceitar também formas de financiamento impuras ou imperfeitas
- Os mecanismos de financiamento e as desigualdades sociais devem continuar sendo criticados e transformados
- Quando um mantenedor encontra uma forma de receber dinheiro, celebrá-lo é mais benéfico para o open source como um todo
1 comentários
Opiniões no Hacker News
É difícil concordar com a parte que coloca “algo que não é uma licença aprovada pela OSI” na categoria de open source
O motivo de não ter aprovação da OSI é que, no sentido definido pela comunidade há muito tempo e que continua válido, não é open source
Além disso, não me atrai o argumento de tratar como vitória várias coisas de naturezas diferentes. Por exemplo, “ser contratado pela Microsoft para trabalhar em Python” também pode ser mais uma armadilha do que uma vitória, dependendo dos detalhes do cargo; basta ver https://ghuntley.com/fracture/
O texto inteiro explica por que ele rejeita deliberadamente a definição da OSI, mas o argumento contrário parece apenas apelar à definição da OSI, que ele rejeitou explicitamente
Ele diz que usa de propósito “open source” / “free software” em minúsculas, não o Open Source™ da OSI nem o Free Software™ da FSF, mas em um sentido amplo de “software com código-fonte que pode ser lido, modificado e cujas versões derivadas podem ser distribuídas sob certas condições”
Por isso, ele diz incluir não só licenças OSI/FSF, mas também Polyform, JSON license e BSL dentro do seu próprio “open source”
Parece mais um argumento para considerar várias formas de trabalho pago como “open source”
Por exemplo, se o RHEL ainda é open source, os programadores da Red Hat são desenvolvedores open source remunerados; mas, se o RHEL agora é software proprietário, o número de pessoas pagas para trabalhar em open source diminui
Só que “essa definição ainda é a mais adequada hoje?” é justamente o ponto central da discussão
Talvez seja adequada, mas questionar essa definição também é uma pergunta plenamente válida, e vejo que é isso que as pessoas estão fazendo agora
Hoje a OSI só aprova uma nova licença quando considera que ela preenche uma lacuna que as licenças já aprovadas pela OSI não cobrem; portanto, existem incontáveis licenças possíveis que satisfazem todos os critérios da definição, mas não seriam aprovadas
[1] https://opensource.org/osd/
Algumas semanas atrás, enviei uma carta a um senador nos EUA dizendo que não há nenhum apoio do governo a engenheiros independentes e pequenos projetos FOSS
A NLNet da UE é excelente, e os EUA realmente precisam de algo como a NLNet
Dito isso, conhecendo diretamente a execução de projetos de transporte e vendo o enorme desperdício que existe ali, não consigo decidir, porque esse tipo de apoio também poderia acabar piorando a situação
Tenho vontade de concordar e entendo a posição, mas, quando se usa a palavra “sempre”, a nuance desaparece
Se uma empresa paga alguém para trabalhar em open source e empurra o projeto em uma direção contrária aos interesses de outros usuários, isso pode ser uma coisa boa? Acho que não
Sou a favor do sustento das pessoas, mas o fato de surgir código-fonte “até certo ponto livre” não torna aceitáveis más condutas
A ideia central é não deixar o perfeito impedir o bom
Devemos trabalhar para que todos que queiram atuar em bases de código open source recebam financiamento público adequado, mas, enquanto isso, também precisamos aceitar a realidade de empresas financiando parte do código FLOSS
Dizer que o governo deveria apoiar parece bonito, mas, se o governo na prática não o faz, isso pode acabar significando que “mantenedores de open source não devem receber dinheiro”
Se a comunidade e os usuários não financiam, empresas privadas financiam, e então elas passam a ter poder de voz
Open source não deve virar “trabalho gratuito” terceirizado para grandes empresas explorarem
O modelo freemium, como no ecossistema WordPress, mantendo uma versão gratuita GPL2+ enquanto vende downloads de add-ons avançados, licenças de atualização e suporte, tem sido o que funciona melhor
Open source é parecido com política: quem coloca o dinheiro tem o poder de decisão. Se a comunidade não for economicamente autossuficiente, o financiamento externo vai definir a direção
Muitas contribuições open source são motivo de orgulho e merecem elogios, mas, durante o dia, a maioria trabalha para empresas privadas que querem aumentar participação de mercado e controle econômico
Com uma mão contribuem para open source, mas, com a outra, por causa do trabalho que fazem em empresas privadas, acabam desfazendo parte desse efeito
Por isso, open source precisa se financiar por conta própria e se tornar uma força econômica e política independente. Caso contrário, continuará sempre do lado que aceita as regras e terá de seguir lutando contra tentativas do lobby privado de prejudicar o open source
Em geral há entregáveis dentro de um prazo específico e, nesse momento, o open source deixa de ser um hobby em tempo integral e é elevado à categoria de profissão
É pouco provável que a direção para a qual uma empresa leva um projeto seja boa, mas também não dá para dizer que seja sempre ruim
Dá para imaginar uma situação em que a direção desejada pela empresa tenha muito mais usuários potenciais, e os poucos usuários existentes possam fazer um fork
É um bom contexto para lembrar a Open Source Initiative e a origem de sua definição
A OSI explicou, em sua própria história em 2007, que havia decidido abandonar a postura moralista e confrontacional associada no passado ao “free software” e vender a ideia pelos motivos práticos e comerciais que haviam movido a Netscape, adotando o termo “open source” e a retórica pragmática e favorável ao mercado desenvolvida por Raymond
É um pouco engraçado que, décadas depois, usuários de licenças não aprovadas pela OSI que tentam impedir a exploração por grandes empresas sejam criticados de forma bastante moralista por não serem “open source de verdade”
http://web.archive.org/web/20071115150105/https://opensource...
Estas últimas muitas vezes impedem hospedar serviços que usam código sob licença BUSL, criando risco de negócio
Surgem perguntas como: é preciso consultar um advogado para saber se um caso de uso específico é permitido; como saber quando se ultrapassa o limite, mesmo que hoje esteja tudo bem; se isso se aplica quando o serviço gera receita ou apenas quando é oferecido diretamente a clientes
Em empresas com uma estrutura de consultoria em que até serviços entre equipes internas têm cobrança interna, como IBM ou Collins, isso pode ser um problema mesmo que clientes externos não paguem por ele
Também não fica claro se, quando o upstream não responde a bugs ou solicitações de recursos, é possível contratar desenvolvedores para contribuir, integrar ao ferramental e à infraestrutura internos, ou misturar livremente com projetos maiores
Independentemente do aspecto moral dessas licenças, apenas do ponto de vista de negócio já dá para explicar a preocupação de que elas não sejam adequadas à OSI e, portanto, também não sejam “open source” no espírito da coisa
A comunidade com que mais me envolvi nos últimos anos foi a R/tidyverse
Alguns desenvolvedores são remunerados por organizações como a RStudio (hoje Posit) e o R Consortium para trabalhar em software, documentação e atividades de comunidade
Minha experiência como programador nessa área foi excelente. Quando há contribuidores de OSS financiados em tempo integral, pessoas com enorme efeito de alavanca passam muito tempo no projeto, e milhares de entusiastas de R se beneficiam disso
Ao usar bibliotecas como os pacotes tidyverse, Shiny e RMarkdown, a documentação é muito bem organizada e os exemplos são simples e excelentes
Muitas vezes, quando você supõe mais ou menos que algo vai funcionar de determinada forma, acerta de primeira, e em muitos casos a própria função ou pacote foi projetado assim desde o início
Parece que ter ao menos uma pessoa dedicada já melhora muito a qualidade de um OSS, talvez porque ajude a organizar dezenas de pequenas contribuições
Projetos open source muitas vezes recebem menos atenção em áreas essenciais como documentação e experiência do usuário. Entre meus projetos OSS favoritos há alguns com experiência de usuário horrível, aparentemente porque os contribuidores gostam de adicionar funcionalidades, mas não costumam assumir o papel de organizá-las em um pacote coerente para o usuário nem de remover contribuições desnecessárias e confusas
Em comparação com comunidades que têm poucos ou nenhum contribuidor OSS financiado em tempo integral, há muito mais pequenos incômodos e inconsistências em bibliotecas, interoperabilidade e especialmente documentação
A comunidade R foi um exemplo impressionante de quanto remunerar dezenas de pessoas de OSS em tempo integral pode beneficiar uma comunidade no longo prazo, e sou grato por poder ficar sobre os ombros desses gigantes humildes
Concordo com a frase “toda vez que um mantenedor encontra uma forma de ser pago, é uma vitória”
Isso está se tornando mais comum, e há muitos casos dignos de comemoração [0]
[0] https://fossfox.com/
Faço doações para vários projetos open source
Há projetos, como o kernel Linux, que parecem ficar bem sem minha doação, mas, se eu acreditar que ela é necessária, não hesitarei em doar
Quanto aos demais projetos, eu preferiria vê-los fracassar a comprometer a definição de open source. Para mim, as duas coisas significam o mesmo
Não sei quando FOSS passou a ser entendido não como “livre como liberdade de expressão”, mas como “grátis como cerveja grátis”
Muitas discussões relacionadas à remuneração de desenvolvedores parecem misturar essas duas coisas
Open source significa que o código é aberto e que há liberdade para vê-lo e modificá-lo, não que o custo seja zero
Em código, o modelo de vender um produto de software enquanto se libera o código livremente pode não ser um modelo de negócio muito realista, mas ainda assim se enquadra na definição de open source
A liberdade de hackear e modificar sempre foi inseparável do custo de licença zero
Se as primeiras licenças livres/abertas tivessem permitido acesso ao código-fonte e modificações, mas cobrado taxa de licença, ou se o FOSS inicial permitisse uso gratuito, mas proibisse modificações, não teria tido o sucesso que teve
As duas liberdades de “free software” sempre estiveram conectadas
Elas não se importam com liberdade, mas todo mundo se importa com custo
Até muitos desenvolvedores FOSS se recusam a receber dinheiro e rejeitam quem recebe. Para eles, dinheiro é como criptonita
Vejo essa filosofia, que contraria a lei extremamente fundamental de que tudo exige compensação, inclusive o tempo das pessoas, como uma das grandes razões pelas quais o FOSS fica para trás em relação ao software comercial e proprietário/fechado
Como o usuário não precisa investir, ele se expande para um mercado potencial muito maior do que seria possível se fosse pago
Há algo no fato de ser grátis que atrapalha o julgamento das pessoas
Em um estudo em que chocolates eram oferecidos de graça ou por US$ 0,01, mesmo quando o chocolate de US$ 0,01 era muito mais sofisticado e oferecia melhor valor, a opção gratuita era muito mais popular
Muitos usuários só querem baixar alguma coisa, usar por alguns minutos e pronto. Ou, pelo menos, querem testá-la e saber que, no pior caso, podem voltar para a versão gratuita, evitando a sensação de ter feito um mau investimento
Este texto interpreta “mas isso ainda não é open source” como uma crítica à distribuição de software sob várias licenças com código disponível
Algumas pessoas podem dizer isso nesse sentido, mas, para mim, trata-se apenas de não diluir um termo que tem um significado claro
Às vezes, uma licença com código disponível é melhor para o negócio, e entendo por que empresas fazem isso
É uma escolha menos generosa, mas ainda assim é algo positivo. Do mesmo modo que é compreensível não abrir o código-fonte de todo software
Vejo as organizações tecnológicas em formato de cooperativa como o futuro
Como as pessoas não querem trabalhar de graça, as contribuições para software open source inevitavelmente sempre ficarão atrás das empresas privadas
Fico curioso para saber se existem projetos open source que monetizam e remuneram os contribuidores
Se um dia eu criar uma startup bem-sucedida, pretendo explorar esse modelo