Devo transformar minha empresa em open source? (2022)
(supabase.com)- A Supabase escolheu ser open source desde o início e, ao construir o produto em público, obteve benefícios maiores do que o esperado em comunidade, contratação e expansão do produto
- As preocupações mais comuns são críticas à qualidade do código, exposição de vulnerabilidades de segurança e cópia por concorrentes, mas a abertura também pode levar a mais participação em melhorias e iteração rápida
- Em contratação, contribuições no repositório mostram o código real e a forma de colaboração do candidato; a Supabase só começou recrutamento outbound depois de contratar 32 desenvolvedores
- Recursos para poucos usuários, integrações e adaptadores podem ser criados pela própria comunidade, ampliando o escopo do produto e compensando os limites de prioridade da equipe interna
- A defesa de uma empresa open source vem menos de esconder o código e mais de acumular velocidade de execução, marca, equipe e comunidade ao longo do tempo
Por que a Supabase escolheu open source desde o começo
- A Supabase foi open source desde o primeiro dia, e como os fundadores eram usuários e apoiadores de longa data de projetos públicos como PostgreSQL, Python, Bitcoin e React, isso não pareceu uma decisão difícil na época
- Ao contrário da expectativa de que construir um negócio em público seria pesado, vários benefícios inesperados apareceram no processo de fazer o produto e a empresa crescerem
- Embora venha da experiência de uma empresa de ferramentas para desenvolvedores ou de PaaS, muito disso também pode se aplicar a empresas de software em geral
- Há três preocupações recorrentes que impedem a transição para open source
- As pessoas podem criticar um código bagunçado ou inacabado
- Hackers podem encontrar falhas de segurança e explorá-las
- Concorrentes podem roubar a propriedade intelectual
A preocupação de “meu código é ruim”
- A ansiedade sobre código ruim está, na maioria das vezes, mais próxima de uma questão de ego; se alguém dedicou tempo para olhar, provavelmente encontrou ali algo que vale a pena perseguir
- Como na história de Stone Soup, quando uma boa ideia é compartilhada com a comunidade, outras pessoas podem adotá-la e melhorá-la juntas
- A comunidade pode refatorar ou substituir código ruim, e também introduzir novas diretrizes de qualidade de código, melhorando o processo de contribuição dali em diante
- Membros tóxicos que só reclamam do código e não sugerem melhorias não são, desde o início, o tipo de integrante desejado para a comunidade
- Contribuidores de open source têm um “cemitério” de projetos antigos, e isso vira uma biblioteca de ideias e abordagens para quem quer construir algo parecido
- Alguém pode se inspirar em uma forma específica de resolver um problema
- No mínimo, isso reduz o tempo gasto repetindo os mesmos erros
- É mais provável que um projeto antigo seja útil ou simplesmente ignorado do que acabe destruindo a reputação de alguém
Código aberto e segurança
- Ao operar uma solução hospedada com código aberto, o maior medo é que um agente malicioso leia o código, encontre vulnerabilidades e invada o serviço
- Na experiência da Supabase, a frase da lei de Linus — “dado olhos suficientes, todos os bugs são superficiais” — também se aplica a problemas de segurança
- Desde o início, pesquisadores de segurança, muitas vezes anônimos, ajudam a examinar o código e a plataforma em busca de problemas potenciais
- Se você oferece SaaS, deve fornecer uma orientação simples em
/.well-known/security.txt, para que pesquisadores bem-intencionados saibam como divulgar problemas potenciais - O Bitcoin é citado como exemplo de como um projeto público pode ser mais seguro do que uma base de código proprietária
- Em uma palestra de 2015, Andreas M. Antonopoulos disse que sistemas bancários fechados têm um sistema imunológico fraco do ponto de vista de software
- Em sistemas fechados, grandes falhas de segurança podem ficar escondidas por muito tempo e, quando enfim são exploradas, causar grandes danos
- Em protocolos open source como o Bitcoin, as falhas de segurança ficam visíveis para todos, os exploits são descobertos cedo e com frequência, e então corrigidos
- Como empresas de software bem-sucedidas podem ser construídas ao longo de mais de 10 anos, no longo prazo um sistema open source pode se aproximar mais de um estado seguro do que um sistema proprietário e sigiloso
- Em um período de competição extremamente acirrada para contratar excelentes engenheiros de segurança, o valor da revisão pública aumenta ainda mais
Concorrentes e preocupações com propriedade intelectual
- Em software, ideias são baratas, e o valor quase sempre é criado na execução dessas ideias
- Ao compartilhar ideias com o mundo, você pode focar mais em iterar rapidamente do que em se preocupar com quem terá acesso à base de código
-
Construir uma comunidade de especialistas
- Para construir uma empresa bem-sucedida, é preciso executar bem por um longo período, por exemplo 10 anos, e ampliar a base de clientes
- Nessa corrida de longa distância, a vantagem que um concorrente ganha ao olhar a base de código provavelmente não será grande quando vista ao longo dos 10 anos completos
- Nesse período, a base de código provavelmente será iterada e refatorada várias vezes
- No longo prazo, a forma de vencer é construir a equipe e a comunidade que melhor iteram e melhoram a própria solução no mundo
-
Vencer no mercado
- Se um mercado total endereçável (TAM) grande e em crescimento realmente vale a pena perseguir, é improvável que seja um cenário de vencedor leva tudo
- É preciso primeiro encontrar um segmento de usuários que você consiga encantar e então iterar rápido
- O tempo gasto focando nos concorrentes é tempo que poderia ser usado para melhorar o produto ou a equipe
- Se um concorrente pode fazer fork do seu projeto open source e lançar mais rápido, então essa era uma disputa que você provavelmente perderia de qualquer forma
- Como PI e patentes em software são notoriamente difíceis de executar, reduzir a preocupação em proteger ideias de software com advogados economiza tempo, dinheiro e energia mental
- Um negócio pode ser melhor protegido sendo a empresa que melhor implementa a ideia de software no mundo
-
Competição com nuvens em estágio mais avançado
- Quando um projeto atinge uma escala considerável, ele pode enfrentar a situação em que grandes provedores de nuvem, como Elastic ou Mongo, oferecem o produto com um modelo de distribuição mais forte
- O maior problema de uma empresa que está começando é, antes de tudo, chegar até esse ponto
- Se a AWS estiver disposta a tirar recursos de uma de suas linhas de produto multibilionárias para competir com você em produto hospedado, isso já significa que você está indo muito bem
- A resposta mais construtiva é descobrir com antecedência áreas em que você pode se manter à frente na competição com qualquer um
- Muitos provedores de nuvem costumam ter uma experiência do desenvolvedor (DX) ruim, então DX pode virar uma competência central
- Se, daqui a 6 anos, o Google tentar roubar seu espaço, sua marca, equipe e comunidade já devem ter passado anos se preparando para uma luta estilo Davi contra Golias
- É preciso planejar isso desde o começo para não ser pego de surpresa, usando tempo e foco para criar uma estratégia vencedora
- Se o concorrente está vindo atrás de ideias, ele estará sempre um passo atrás, e especialmente no início, quando os recursos são escassos, você acabará gastando ainda mais energia se preocupando com a concorrência
Efeito na contratação de desenvolvedores
- Um dos grandes problemas que startups enfrentam, independentemente do tamanho, é a dificuldade de contratar desenvolvedores
- É difícil fazer sourcing
- É difícil avaliar desenvolvedores
- É difícil convencer candidatos do nível dos futuros colegas
- Open source pode ajudar a reduzir esse problema de contratação
-
Sourcing público
- Todos os desenvolvedores se beneficiam de open source, e muitos querem retribuir contribuindo para projetos open source interessantes
- As razões para contribuir podem incluir uma boa comunidade, aprender novas tecnologias e a diversão de resolver problemas técnicos difíceis em uma base de código desconhecida
- Se você diminuir a barreira para contribuição de código em um projeto open source, grandes desenvolvedores podem acabar encontrando o projeto
- Contribuidores podem participar de discussões em issues, correção de bugs, identificação de problemas e revisão de PRs
- Nem todo contribuidor está procurando emprego, mas muitos podem se sentir atraídos pela perspectiva de trabalhar em tempo integral com código open source
- A Supabase só começou recrutamento outbound depois de operar por mais de 2 anos e contratar 32 desenvolvedores
- Open source foi o principal canal de descoberta de talentos da Supabase e continuará sendo
- Em uma empresa remota e assíncrona, a estratégia de contratação via open source permite que o próprio candidato demonstre suas capacidades, facilitando a validação dessas competências
-
Contribuições reais no lugar de LeetCode e testes por tarefa
- Uma das maiores reclamações dos desenvolvedores ao procurar o próximo emprego é ter que resolver problemas de LeetCode ou fazer testes em formato de tarefa durante o processo seletivo
- Esse tipo de abordagem consome muito tempo, é cansativo e muitas vezes não representa o trabalho real que será feito
- Quando alguém contribui para o repositório, já existem materiais como
- exemplos de como a pessoa se comunica com a equipe e os membros da comunidade em um ambiente remoto e assíncrono
- exemplos de contribuições reais de código
- O candidato também pode avaliar a empresa
- Pode verificar se a equipe valoriza qualidade de código
- Pode ver se ela se comunica de forma eficaz
- Pode julgar se toma boas decisões técnicas
- As pessoas contratadas por meio dos repositórios da Supabase se tornaram indispensáveis por conta própria; algumas passaram a liderar o desenvolvimento de repositórios existentes ou iniciaram novas bibliotecas cliente e SDKs
- Elas não precisaram resolver problemas de LeetCode no Zoom
Expansão de recursos de nicho e integrações
- Ao criar uma startup, muitas vezes só há tempo para resolver os maiores problemas
- Para se mover rápido, é preciso focar no que 80% da base de usuários pede {p:80}
- Recursos pedidos por uma minoria de usuários tendem a ser adiados indefinidamente
- Se o sistema for open source, esses usuários podem contribuir diretamente com os recursos, aumentando a utilidade do software
- Esse efeito aparece com frequência em integrações e adaptadores
- Usuários podem querer integração com Azure ou Vercel
- Se outra pessoa disponibilizar recursos de desenvolvimento para criar essa conexão, todos os usuários do projeto se beneficiam
Não reinventar a roda repetidamente
- Em um mundo sem open source, empresas de tecnologia continuam reinventando a roda sem parar
- A Supabase não apenas libera novos projetos como open source, como também tenta apoiar projetos open source existentes antes de criar algo novo
- A situação em que montadoras usam funções proprietárias, elementos de UI proprietários, bibliotecas de janelas proprietárias, sistemas operacionais proprietários e drivers proprietários para exibir mensagens de erro que quase ninguém verá é um desperdício de tempo e esforço de desenvolvedor
- A Launch Week da Supabase é um conjunto dos resultados do trabalho da equipe e da comunidade nos últimos 3 meses, e a vantagem de operar uma empresa open source aparece no ritmo de avanço da comunidade
- Mais detalhes podem ser vistos no post da Launch Week 4, e para participar é possível visitar o GitHub da Supabase
1 comentários
Comentários do Hacker News
Há uma grande suposição escondida aqui sobre lucratividade sustentável, e, especialmente considerando realidades como salários de desenvolvedores nos EUA, isso parece destoar da experiência prática.
Resumindo, uma empresa de código aberto precisa ser atingida por um raio duas vezes: uma vez no projeto open source, e outra na empresa.
A equipe da Graphistry vive e respira open source todos os dias, ajudou a dar início a projetos que levaram ao Apache Arrow e ao Nvidia RAPIDS, e também abriu o código dos clientes Python/JS. O PyGraphistry[AI] é uma espécie de canivete suíço para grafos, e também inclui ferramentas implementadas de forma a permitir embutir linguagens de consulta de grafos como GFQL e Cypher, com suporte nativo a dataframes e até aceleração por GPU.
Mas o crescimento sustentável vem principalmente da venda de licenças self-hosted em nuvem/on-premises do servidor de visualização de grafos com GPU para empresas, governos e companhias de dados. Depois de anos resistindo, felizmente esse negócio está crescendo bem, e embora a receita de hospedagem SaaS por si só sustente uma equipe pequena, ela não cobre a maior parte da equipe. Sem a receita das licenças self-hosted, a maior parte do ciclo de inovação desapareceria.
Este texto parece ignorar a interseção entre sorte de ganhar na loteria, características do mercado SaaS e defensabilidade técnica. O lançamento do Louie.AI e do GFQL está mudando, no nosso caso, a viabilidade comercial do open source, então não quer dizer que seja impossível, mas olhando para a trajetória até aqui, fico preocupado com novos fundadores que lerem este texto.
[1] https://graphviz.org/
Em outras palavras, a questão é se seriam clientes que diriam “agora vamos abrir o código” e responderiam “ótimo, então vou cancelar o contrato”.
Foi dito que “quando converso com outros fundadores sobre modelos de negócio open source, há três preocupações recorrentes: as pessoas podem criticar código bagunçado, ruim ou inacabado; hackers podem encontrar e explorar falhas de segurança; concorrentes podem roubar propriedade intelectual”, mas acho que faltou uma quarta.
Amazon/AWS pode comercializar e vender um serviço baseado no meu código sem me pagar nada.
Quando interajo com usuários e recebo feedback, mantenho a educação, mas por dentro penso “falar é fácil. Eu realmente construí isso. Fica quieto ou manda um PR”. E, sem surpresa, essas pessoas quase nunca mandam PR.
Basta continuar construindo de verdade e ignorar quem só critica.
[0] - https://heywillow.io/
Se grandes empresas estão tentando copiar, você já está vencendo, e é preciso ter um plano prévio para mitigar isso. Mas, se interpretei o texto corretamente, a ideia é que isso não é algo em que se deva focar ou se preocupar no estágio inicial.
O motivo de empresas de nuvem engolirem outros produtos open source é que esses produtos não escolheram licenças que protegessem adequadamente o trabalho delas.
É um texto realmente profundo e muito bom, mas há uma coisa que muitos projetos deixam passar: dá para vender para o setor governamental não militar.
O governo dos EUA tem muitos programas técnicos, como bolsas da NSF, e instituições civis, agências de inteligência e governos estaduais são fragmentados entre si, o que acaba criando um cenário de compras de software imensamente amplo. As barreiras regulatórias e de compliance também não são tão altas quanto se imagina, especialmente se você conquistar os primeiros contratos junto com parceiros. Em geral, é uma receita estável e garantida, capaz de financiar projetos com compromissos de 3 a 5 anos, além de ser extremamente lucrativa.
Gostaria que mais empresas open source aproveitassem isso. Muitas vezes, empresas totalmente privadas colocam bibliotecas open source em seus produtos, aplicam margens enormes e ficam com tudo.
Exemplo: https://x.com/ssankar/status/1749202248700420587?s=20
Quando eu estava no governo, vi muito software que era basicamente uma combinação de mapa open source + banco de dados open source custando US$ 12 milhões. Em outros casos, também vi US$ 2 milhões por ano para OCR de PDF e US$ 30 milhões por ano para ferramentas tipo weights & biases.
Além da distribuição de software, há outros incentivos. Por exemplo, corrigir com prioridade certos bugs ou falhas de segurança. É bem possível que agências de inteligência tenham pago muito dinheiro ao safetensors.
A Supabase tem quatro caminhos possíveis: venda direta ao Cybercom, venda direta ao DOS ou por contrato de equipe, venda ao VA via PWS, ou venda direta a grandes fornecedores de software contratados pelo governo.
Na prática, isso se faz enviando cold emails para alguém de nível GS 14/15 ou equivalente, contratando um ex-GS15, ou procurando licitações adequadas no SAM.gov e então montando propostas com o GovPro.ai em modo full-service, ou com o rogue de forma direta.
Quando a burocracia governamental finalmente aprova um contrato, a maioria das startups provavelmente já ficou sem dinheiro.
Os contratos podem ser lucrativos, mas a burocracia é enorme e você precisa de alguém com experiência para lidar com isso. Não é um caminho adequado para todo mundo, e exige muito tempo e negociação.
Mesmo deixando de lado a burocracia gigantesca, o governo federal é a entidade governamental maior, mais lenta e mais difícil de lidar. Só nos EUA há dezenas de milhares de outras entidades governamentais, como escolas, cidades, condados, estados, distritos de água e bombeiros, bibliotecas etc.
Se você quer entrar no setor público, é melhor não apostar tudo nos maiores e adotar uma abordagem menor e mais ampla.
O setor governamental mais lucrativo do mundo é o Departamento de Defesa dos EUA.
Mas o Departamento de Defesa é incrivelmente burocrático, sensível a cronogramas e obcecado por sigilo.
O modelo de negócios da Supabase é se vender como uma empresa de código aberto, mas, na prática, ninguém em sã consciência tentaria hospedar por conta própria em produção
por causa de documentação sutilmente incompleta, bugs sutis e recursos importantes sutilmente ausentes. Então ela recebe elogios por ser open source, mas na prática não é algo útil, e eu vejo isso apenas como uma ferramenta de marketing
A primeira é a tranquilidade. Mesmo que você não faça self-hosting agora, isso cria uma rota de saída extra caso o serviço deixe de te agradar. Claro, também é preciso oferecer acesso aos dados brutos
A segunda é a qualidade do código. Se você já lidou com código horrível que por fora parecia funcionar bem, sabe o quanto é importante ter um código que não dá vergonha de tornar público
A terceira é a possibilidade de contribuição. Antes eu achava isso pouco relevante, mas depois de passar por isso várias vezes, percebi como é valioso poder pedir ou contribuir diretamente quando faltam recursos, há bugs ou problemas de desempenho. Na maioria dos projetos de código fechado, você já tem sorte se existir ao menos um canal transparente para pedir funcionalidades
Se ela passar de certo limite, as pessoas podem decidir investir esforço em um fork. MariaDB é um exemplo
Já houve gente que me disse diretamente que esse é exatamente o motivo de se sentir mais segura usando o serviço gerenciado da nossa empresa
Parece muito mais fácil ser uma empresa de código aberto legítima e de verdade
Se não era isso que você queria dizer e eu interpretei mal, então o restante do texto na verdade faz a Supabase parecer muito positiva
Talvez isso não seja viável comercialmente, mas o estado atual corrói fortemente o padrão do que se pode esperar de software open source, e também não parece trazer um ganho claro de longo prazo para as empresas que escolheram esse caminho
Mesmo que o desenvolvedor não execute o software por conta própria, isso permite ver o código que realmente está rodando
Gosto da Supabase, gosto do open source comercial de forma geral e concordo com grande parte do texto
Mas a parte de que “em software, ideias são baratas. O valor quase sempre é criado na execução das ideias” soa estranha
Já ouvi essa frase em contextos como “tenho uma ideia incrível de startup, você assina um NDA antes de eu contar?”
Só que, ao abrir um software como open source, você não está oferecendo apenas a ideia, mas também uma parte substancial da execução dessa ideia
Claro, código não é toda a execução, e isso se estende a vendas, marketing, suporte etc. Ainda assim, o texto minimiza demais o valor do código e insinua que, sem vendas e marketing, ele não vale nada, e eu não acho que isso seja verdade
Se eu fosse dividir o valor, diria algo como 90% vendas/marketing/validação com clientes e 10% código. Toco um SaaS bootstrapado com receita anual de sete dígitos baixos, e posso dizer que o código em geral é uma bagunça e está sempre evoluindo
Você não consegue copiar uma casa de graça, mas software consegue
O que o desenvolvedor recebe para fazer é o processo de criar o código e resolver todos os probleminhas invisíveis
É por isso que vender software é tão lucrativo. Se você não vender o software, não dá para ganhar dinheiro com ele. Software não é como objetos físicos da realidade que compartilhamos
Para mim, a pergunta central não é se o código é bom o bastante ou se concorrentes vão copiá-lo, mas se dá para ganhar dinheiro suficiente para construir um negócio sustentável
Projetos open source amados e muito citados não são bons negócios: PostgreSQL, Python, Bitcoin, React
Mongo e Elastic são ótimos, mas são exceções. Há mais empresas bem-sucedidas de banco de dados de código fechado do que empresas de banco de dados open source
Empresas open source são difíceis. Mas têm enorme valor para os usuários
Deixando de lado a discussão sobre qual licença conta como “open source”, o importante é que essas empresas concluíram que licenças amplamente usadas como (A)GPL, Apache e MIT deixam espaço demais para concorrentes criarem serviços gerenciados/hospedados e competirem em escala. Um exemplo foi a Amazon oferecendo o OpenSearch mais barato que o ElasticSearch
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
Parece que essa pergunta está sendo usada no sentido de “nossa empresa deve divulgar o código-fonte do software?”
Mas, para mim, responder à pergunta original ajuda a responder a reformulação. A pergunta original trata não do software que a empresa vende, mas da natureza do software que ela usa
Pessoalmente, se houver alternativa, eu sempre vou escolher um produto open source. Mesmo que isso signifique pagar com gosto pelos custos de suporte ou doar para o projeto. O acesso livre para ver o código-fonte é algo fundamental para mim, mesmo em software que eu jamais pretenda modificar
Sei que para muita gente isso parece uma posição extrema. Mas eu detesto a ideia de não poder desmontar um micro-ondas, uma maçaneta ou uma transmissão. Talvez eu não consiga montar tudo de novo direito, mas talvez eu consiga achar uma engrenagem quebrada e fazer um reparo de 2 dólares em vez de uma troca de 90 dólares. Ou talvez eu faça um micro-ondas Frankenstein com transmissão
Para mim é importante poder estender a funcionalidade de um servidor web ou entender por que meu plugin faz o aplicativo hospedeiro travar. E acho que isso também é importante para a sociedade. Por isso continuo firme no meu extremismo open source. Mesmo que você me mostre o mais novo servidor web ultracompacto com IA embarcada que processa HTTPS/4 em 5 KB, eu até ficaria interessado, mas se não for open source vou continuar usando a stack atual
Por causa dessa mentalidade, o software que eu crio é open source, e às vezes as pessoas pagam por isso
Sobre a parte de que “se daqui a 6 anos o Google tentar roubar seu almoço, você precisa ter uma marca, equipe e comunidade que tenham se preparado nos últimos anos para uma luta de Davi contra Golias”, pela minha experiência, para a área de compras coisas como marca, comunidade, equipe e experiência do desenvolvedor quase não significam nada em comparação com compliance
Isso é ainda mais verdade se você estiver competindo de frente com um fornecedor estabelecido como o Google
No caso da Supabase, isso é uma observação precisa, porque de fato passamos os últimos anos nos preparando em compliance como SOC2, HIPAA e GDPR para atender esse tipo de exigência
Nós também pensamos bastante sobre essa questão no nosso produto. Em algum momento vamos abrir tudo como código aberto sob licença MIT ou Apache, dependendo da que parecer melhor na época, e isso já está público no site. Não será AGPL nem open core
Mas senti que ganhar dinheiro com o produto nesse formato era completamente inviável, e também foi assim nas minhas experiências anteriores. Consultoria até pode funcionar, mas produto é diferente. A Supabase recebeu um investimento de venture capital enorme, e praticamente todo projeto open source “grande” também
Se você está fazendo bootstrap, especialmente em um projeto ambicioso e difícil, por um tempo você simplesmente não consegue emitir cobranças. As pessoas só conseguem trabalhar de graça por um período limitado, e uma equipe pequena com código fechado, se comunicando de perto o tempo todo, consegue se mover muito mais rápido reduzindo a sobrecarga necessária para um projeto open source bem-sucedido
Gostaria de ouvir exemplos de projetos de porte parecido, com US$ 0 em investimento, iniciados nos últimos 5 anos, com mais de 2 pessoas em tempo integral, que tenham durado mais de 3 anos e ainda recomendem essa abordagem. Queria saber como estão sustentando o negócio. Acho que casos como o Redis não acontecem mais. Pelo menos eu não vi. Até mesmo um projeto simples como o langchain recebeu dezenas de milhões de dólares em venture capital, sendo que eu consideraria justamente esse tipo de projeto um candidato que uma equipe pequena poderia tocar ganhando dinheiro com várias fontes de receita
Todo o meu software é publicado em domínio público, ou seja, como software livre, mas nenhum deles se tornou um projeto open source ou comunidade de sucesso. Software livre é antes de tudo uma ideologia; prática ou funcionalidade vêm depois
Acho que abrir uma empresa como open source só faz sentido se você estiver mirando desenvolvedores ou construindo um produto que, na prática, quase ninguém vai hospedar por conta própria
A Supabase é o exemplo clássico dos dois casos. Um exemplo do segundo é o Plausible Analytics: dá para hospedar por conta própria. Eu mesmo faço isso com o Coolify.io. Mas, se você não criar um sistema próprio de CI/CD para buscar e mesclar as atualizações das releases, vai acabar ficando para trás nas atualizações