- O projeto WiX Toolset adotou a política Open Source Maintenance Fee (custo de manutenção de código aberto) para garantir a sustentabilidade de longo prazo
- O código-fonte continua disponível gratuitamente de acordo com a licença, mas a política de custo de manutenção passa a valer para a maioria das atividades, como registrar issues, escrever comentários e baixar novos releases
- Em especial, se você usa este projeto para gerar receita, será obrigatório pagar esse custo de manutenção
- O pagamento pode ser feito tornando-se um GitHub Sponsor
- Organizações pequenas (menos de 20 pessoas): $10/mo
- Organizações de porte médio (20 a 100 pessoas): $40/mo
- Organizações grandes (mais de 100 pessoas): $60/mo
- Mais detalhes sobre a política estão disponíveis no site oficial do Open Source Maintenance Fee
2 comentários
Na prática, é praticamente igual ao RHEL.
Comentários no Hacker News
Gostei dessa inovação. A ideia básica é que ninguém quer transformar isso em software fechado, e o código continua livremente disponível para todos, para qualquer uso. Afinal, o custo marginal de distribuir código é praticamente zero. Mas os mantenedores não querem atuar como uma instituição de caridade oferecendo trabalho não remunerado para empresas. O tempo deles é limitado, então é natural querer alguma compensação quando contribuem para atividades que geram receita. Tudo bem que isso não seja perfeitamente obrigatório. Agora os mantenedores ganham a liberdade de responder a reclamações com “se você quer que a gente se importe, pague por isso”. Empresas que pagam recebem certo nível de suporte, e usuários comuns continuam tendo a mesma experiência. Só as empresas que ignorarem esse aviso vão lidar com as consequências, e isso parece especialmente eficaz quando elas apelam com algo como “muitos usuários importantes serão afetados”. Se realmente for necessário, faz sentido pagar. Agora que aumentam o código, os relatórios etc. gerados por IA, isso me parece uma solução bem elegante para um problema frequente no open source
Tenho sentimentos mistos sobre isso. Não sou usuário de Wix, e esse é um comentário geral sobre o caso em si. Ninguém pode ser obrigado a manter um projeto open source. Toda correção é voluntária. Nenhuma empresa pode forçar alguém a aceitar PRs ou fazer trabalho. Desenvolvedores de FOSS muitas vezes ficam sob pressão, mas se não houver motivação financeira, podem simplesmente recusar. Pode haver reclamações, mas não existe obrigação de corrigir o problema. O modelo de patrocínio no fim me passa a sensação de transformar FOSS em modelo de negócio. Aí deixa de ser FOSS. A essência do FOSS é que qualquer um pode copiar, modificar e transformar em negócio. Na maioria das licenças, isso já foi aceito. Talvez minha opinião não seja popular, mas não acho que haja motivo para tanta indignação nesse caso
Quero apontar dois lados negativos dessa política. Primeiro, pode ficar mais difícil atrair contribuintes. Pode surgir uma estrutura de duas camadas, com contribuidores pagos e não pagos. Pode aparecer ressentimento do tipo “eu faço correções de bugs de graça enquanto os outros ganham dinheiro”. Segundo, no momento em que entra dinheiro, a relação fica muito mais transacional. Se houve pagamento, surgem exigências e trabalho correspondente. Claro, o modelo baseado em voluntariado também tem problemas de sustentabilidade
Não acho isso tão inovador assim. É só uma mudança de dar o produto de graça para agora vendê-lo. Ou seja, parece que estão operando como um negócio comum
Acho melhor deixar qualquer pessoa pagar por funcionalidades ou suporte que queira, e manter o código fechado até certo limiar. Esse limiar pode levar meses ou anos dependendo do interesse e da renda. No fim, ele seria liberado como open source. Caso contrário, todo mundo fica esperando que outra pessoa pague. Claro, a estrutura teria de ser bem pensada para evitar forks demais, mas parece perfeitamente viável
Eu já achava que vários projetos open source aplicavam algo assim. Pensei que o caso de consultores que mantêm o Busybox se encaixasse nisso, mas talvez eu tenha entendido a situação errado
Não tem absolutamente nada a ver com o construtor de sites Wix; aqui o assunto é o WiX Toolset
“O toolkit que permite criar as experiências de instalação do Windows mais poderosas. Open source desde 2004!”
Valeu. No começo eu também achei que fosse Wix. A Wix realmente faz muitas bibliotecas React Native de altíssima qualidade
Alguns meses atrás, enquanto avaliava instaladores para meu projeto open source, descobri essa política por acaso. Se o código-fonte estiver sob uma licença da OSI, não tenho problema com a venda de binários. Mas a seguinte frase no README me incomodou: "Para a sustentabilidade de longo prazo deste projeto, o uso do WiX Toolset exige uma taxa de manutenção de open source. O código-fonte é oferecido livremente sob licença, mas todos os demais recursos, como abrir/comentar issues, participar de discussões e baixar releases, também exigem conformidade com a taxa de manutenção. Em outras palavras, uso com fins lucrativos exige a taxa de manutenção." Como isso é um conceito difícil de explicar em poucas palavras, dá para interpretar com boa vontade. Mas resumir como “pague para uso comercial” pode justamente gerar mal-entendidos. Pela licença MS-RL, se você compilar por conta própria e usar, não há restrição mesmo para fins comerciais, então isso me pareceu uma espécie de tática de intimidação para transformar usuários comerciais em patrocinadores. Entendo as dificuldades que mantenedores de open source enfrentam, mas essa abordagem não me pareceu ética. Por isso acabei desistindo de usar o WiX mesmo sem ser usuário comercial
Isso é uma declaração clara de que eles não vão oferecer suporte gratuito para usuários comerciais. Você disse que a explicação não é clara, mas a frase citada diz explicitamente que “o código-fonte pode ser usado livremente de acordo com a licença”
Startups e pequenas empresas com pouco caixa pegam projetos open source, compilam por conta própria, transformam em artefatos de distribuição e administram internamente. Quando chegam a certo porte, passa a valer mais a pena pagar por suporte oficial que cuide de todo esse processo. Essa política serve para incentivar empresas a pagar pelo suporte oficial quando elas não querem assumir o risco de suporte direto de simplesmente baixar e usar binários open source
Realmente não é fácil explicar essa ideia em uma frase curta. As expectativas em torno de projetos open source variam demais. Se alguém tiver sugestão de como melhorar o texto, eu adoraria ouvir
Para mim, a lógica é: se você quer exigir algo representando uma organização com fins lucrativos, então precisa pagar para ter essa conversa. Se a interação busca benefício econômico, ela entra nessa estrutura paga
Lendo os comentários da issue no GitHub, a equipe parece bastante razoável. Pelo que entendi, eles só querem dinheiro quando realmente há fins lucrativos. Se for um desenvolvedor solo de verdade ou um produto em estágio inicial, provavelmente não ligam muito. Também existe uma página de patrocínio
Isso é sobre o próprio site https://opensourcemaintenancefee.org/. Ele só fica legível no modo escuro; no modo claro quase não dá para ler. Também não dá para abrir issues no repositório. Talvez o autor veja este comentário aqui (improvável)
Então era por isso que precisava pagar a taxa de manutenção para abrir issue! Brincadeira
Nossa, isso era um problema sério. Agora já foi corrigido graças a um colaborador aleatório!
Se fosse o jurídico da minha empresa, ao ver uma EULA dessas, em vez de pagar, mandaria parar imediatamente de usar a ferramenta. Acho que a maioria das empresas reagiria assim. Talvez isso seja aceitável da perspectiva dos mantenedores, mas eu sempre defendi que, se você quer manter o open source e ao mesmo tempo restringir uso comercial desse jeito, então deveria usar AGPL. AGPL é praticamente veneno para enterprise. Nenhuma empresa por onde passei permitiria usar código AGPL em produto comercial. Depois disso, basta vender uma licença comercial paga
Projetos open source muitas vezes funcionam como um sistema de caridade e honra. Os contribuidores ganham reconhecimento, e as empresas que usam ganham lucro. Assim os dois lados se beneficiam e, indiretamente, a humanidade também. Eu pessoalmente — talvez de forma ingênua — acho que essa caridade poderia retornar à humanidade de forma mais direta e clara. Por exemplo, quando um projeto for lançado sob licença pública, empresas que lucram com ele doariam algo como 1% da receita para um fundo global, o “Decentralized Universal Kindness Income” (DUKI). Empresas que forem contribuidoras líderes poderiam receber isenção total ou parcial dessa doação, mantendo alguma vantagem mesmo se outras grandes empresas usarem aquilo na concorrência (por isso a Redis também mudou de licença). Os contribuidores ganhariam reconhecimento e prestígio muito maiores no mundo todo, e as empresas doadoras poderiam não só usar amplamente recursos open source, como também obter ganho reputacional em marketing. Isso poderia torná-las muito mais competitivas do que empresas que só perseguem lucro. Eu chamo isso de “licença DUKI”. A essência seria pegar a licença MIT e adicionar uma única condição de compartilhamento de benefícios. Infelizmente, não tenho influência para promover isso, e é incerto se mantenedores centrais e fundadores do ecossistema open source aceitariam a ideia
A frase “o código-fonte é disponibilizado livremente sob licença, mas todas as outras atividades, como abrir/comentar issues, participar de discussões e baixar releases, exigem conformidade com a taxa de manutenção” me chamou atenção, especialmente a parte sobre baixar releases. Não sou advogado, mas isso me parece conflitar com a própria licença. Mais especificamente, com a cláusula que diz que “cada contribuidor concede uma licença autoral não exclusiva, mundial e isenta de royalties para reproduzir, usar, modificar e distribuir sua contribuição e derivados”. Desse jeito, isso só aumenta a confusão e, na prática, força a criação de forks com automação para espelhar releases. Eles já até fornecem a GitHub Action correspondente no repositório
A cláusula de licença que você citou só significa que você ganha o direito de copiar, modificar (ou compilar) e distribuir aquele código. Não existe obrigação de distribuir binários. Na verdade, isso é bem comum. Licenças open source em geral se aplicam só ao código-fonte. A observação sobre “incentivar mirror e fork automáticos” é válida, mas para desenvolvedores de software clonar e compilar por conta própria sempre foi algo fácil e natural. Antigamente, replicar o fonte diretamente era o modo padrão de uso, e foi justamente isso que tornou FOSS popular. Isso não é um “drible”; é a própria essência do FOSS
Concordo completamente. Mas, na prática, não foi isso que aconteceu. A maioria das empresas considerou nossa taxa de manutenção suficientemente razoável e preferiu ter suporte oficial sem risco de manutenção do projeto ou de fork
Talvez eu não esteja entendendo o “hype” em torno disso. A licença não muda, mas quem não paga a taxa de manutenção não recebe suporte? Se alguém reportar uma vulnerabilidade, o denunciante precisa pagar primeiro para o WiX corrigir? Ou, se um usuário corporativo sugerir uma boa funcionalidade, a ideia será ignorada até ele pagar? Isso tudo me parece bastante óbvio. Autores de open source sempre decidiram por conta própria quais PRs aceitar e a quais issues dar atenção. Eles sempre puderam cobrar por suporte. Fico em dúvida sobre o que há de inovador na taxa de manutenção. Não estou tentando atacar. Acho ótimo criar uma ferramenta sob licença open source e também acho natural receber apoio financeiro. Se contribuidores se sentirem alienados, podem sempre fazer um fork. Isso não é um conceito novo. Claro que um fork exige recursos financeiros e humanos consideráveis. Até uma gigante como a Amazon provavelmente acha mais eficiente pagar aos autores originais para conseguir atenção. Há exemplos como LibreOffice, io.js, OpenTofu e neovim. E, se alguém consegue realmente separar um projeto como no caso do LibreCAD, isso também é mérito. O io.js ajudou a tornar o nodejs mais saudável, então teve valor. Essa força da comunidade é uma das grandes vantagens do open source. Qualquer um pode contribuir com código, documentação, dinheiro, ideias etc. Obrigado ao WiX por participar da comunidade dessa forma, e espero que continue indo bem
O instalador WiX é uma ferramenta complexa e difícil de entender. Eu só usava por ser gratuita. Se fosse paga, usaria um produto comercial mais simples e com suporte melhor. Rob Mensching já tentou monetizar com consultoria e suporte por US$ 5.000 por ano, então talvez isso não tenha sido suficiente
Dizer que “ser gratuito era a única vantagem” faz sentido para quem usava uma ferramenta de instalação sem querer gastar. Mas o maior valor do WiX não está só em ser gratuito. O WiX Toolset permite explorar o potencial do Windows Installer de um jeito que nenhuma outra ferramenta de instalação oferece. Se você não precisava desses recursos avançados, então sim, ele era desconfortável e cheio de limitações. Mas, para problemas difíceis de instalação, justamente esses recursos afiados eram indispensáveis. Sobre “monetizar com consultoria de US$ 5.000 por ano”, eu não ganho apenas US$ 5.000 por ano com o WiX em si. Eu ofereço serviços personalizados de alto nível por meio do programa “WiX Developer Direct”, usando o conhecimento sobre empacotamento de instaladores que minha equipe e eu acumulamos por décadas, além das ferramentas avançadas fornecidas pela FireGiant. Oferecemos office hours mensais, garantias de SLA, revisão anual de código, ferramentas avançadas e outros serviços premium, e os clientes valorizam muito isso. Não é que isso não fosse suficiente; o que aconteceu foi que, depois do incidente com o XZ Utils, senti de forma muito concreta como a sustentabilidade do open source é realmente um problema sério. Então tentei encontrar alguma saída, e a Open Source Maintenance Fee me parece uma solução bastante boa para projetos como o meu. O WiX Toolset é atualmente o primeiro a adotar esse modelo, então também está funcionando como campo de testes para entender, com tentativa e erro, como isso funciona na prática. Até agora, tem dado muito certo
O WiX é basicamente uma ferramenta que permite escrever diretamente em XML a estrutura de banco de dados interna usada pelo Windows Installer. Como o formato MSI e o próprio Windows Installer são extremamente complexos, esse tipo de avaliação aparece, mas o problema não é tanto o WiX em si; o formato MSI já é, por natureza, um “labirinto complexo”
Eu achava que a licença era da MS, mas olhando o texto completo da licença, diz que “releases binários publicados no GitHub e no NuGet.org estão sujeitos a uma EULA que exige o pagamento da taxa de manutenção”. Também não sou advogado, mas nesse caso não seria possível contornar a taxa compilando e distribuindo por conta própria? E também não daria para redistribuir esses builds de graça?
O código pertence à .NET Foundation, não à Microsoft (a história é longa). E sim, contornar a taxa compilando por conta própria é totalmente permitido na prática. Agora só falta você assumir a responsabilidade por 500 mil linhas de código. Divirta-se com seu verdadeiro fork!
Segundo o README do repositório, o código-fonte é open source, mas os recursos de issues e releases do repositório exigem o pagamento da taxa de manutenção