Código aberto: o que achamos?
Código aberto: o que achamos?
Desde o lançamento da Cal.com, recebemos incontáveis mensagens de fundadores perguntando se o código aberto seria o caminho certo para a startup deles, e por isso queríamos escrever sobre o processo de decisão de começar a cal.com como uma empresa de código aberto, para ajudar outras pessoas a tomar uma decisão parecida.
Tem havido muito hype em torno do código aberto desde 2021, e algumas revistas de tecnologia estão escrevendo sobre o "Renascimento do Código Aberto", mas queremos ter certeza de que você está fazendo as coisas certas pelos motivos certos — ou, pelo menos, refletindo sobre os seus motivos.
Temos recebido recentemente bastante variações parecidas da pergunta acima (por causa do crescimento e da cobertura da cal.com), e é por isso que queríamos escrever um post explicando como pensamos sobre SaaS vs código aberto e quando tornar algo de código aberto.
Apesar de ambos já termos usado muitos projetos de código aberto antes e apreciado imensamente o trabalho que eles fazem, nenhum de nós se consideraria um fã fervoroso de código aberto. A Cal.com é o primeiro projeto OSS em que qualquer um de nós trabalhou, já que todos os projetos em que trabalhamos antes eram de código fechado. Na maioria das vezes havia um motivo muito bom para esses projetos não serem de código aberto.
Por que construímos a Cal.com, afinal?
Quando o Peer trabalhou na empresa anterior dele, a leanhire.com, ele percebeu que ela precisava desesperadamente de uma ferramenta de agendamento mais poderosa.
Ao contrário do caso de uso típico em que o Peer, ou os funcionários dele, fariam agendamentos (como em vendas ou recrutamento), eles precisavam de um produto de agendamento para o marketplace de contratação deles. Em todo marketplace de dois lados, seus usuários interagem com outros usuários, o que não se encaixa bem no modelo típico oferecido pelos produtos de agendamento existentes.
Ferramentas de agendamento como Calendly, SavvyCal e Motion são produtos incríveis para ajudar você a fazer agendamentos. No entanto, elas não têm a capacidade de fornecer a infraestrutura de agendamento para casos de uso mais avançados, como marketplaces de contratação, telessaúde e muito mais. Por exemplo, não seria viável para um marketplace de contratação pagar $19/mês por cada assento se você tiver mais de 5.000 usuários, como o Peer tinha na Lean Hire.
Produtos SaaS de agendamento existentes também não oferecem muitos insights sobre o que está acontecendo por dentro. No onboarding da Lean Hire, eles pediam anteriormente que os clientes simplesmente copiassem e colassem o link de agendamento, e a plataforma o adicionava automaticamente aos e-mails de prospecção. No entanto, assim que o destinatário clicava no link de agendamento, a plataforma da Lean Hire não tinha a capacidade de rastrear o que acontecia em seguida.
Eles não sabiam se ou quando os eventos aconteciam, nem se eram reagendados ou cancelados. Não havia como alterar o fluxo de trabalho de agendamento, o design ou as chamadas de API que estavam sendo feitas ao reservar. Portanto, era necessária uma solução aberta, acessível e extensível que eles pudessem hospedar por conta própria.
O Peer imediatamente pesquisou no Google por "Calendly open source" porque é isso que o código aberto significa: aberto, acessível, extensível e hospedar por conta própria.
Para surpresa dele, ele não conseguiu encontrar um único projeto fazendo o que a Lean Hire estava procurando. Por coincidência, nessa mesma época, centenas de outras pessoas estavam procurando exatamente a mesma coisa. Threads em fóruns, discussões no Reddit e muito mais foram abertos por pessoas perguntando se existia um produto de agendamento de código aberto que pudesse rivalizar com as soluções SaaS mais populares.
Por que tornamos a Cal.com de código aberto?
Desde o primeiro dia ficou óbvio para nós que a Cal.com seria um projeto de código aberto. As coisas que pretendíamos fazer eram fundamentalmente mais difíceis sendo um produto SaaS fechado do que sendo de código aberto.
O ponto-chave aqui é que as limitações dos produtos de agendamento existentes só poderiam ser resolvidas com código aberto. Muitos fundadores seguem pelo caminho errado achando que devem construir uma alternativa de código aberto para um produto existente, pensando que o produto deles vai vencer simplesmente porque é de código aberto. Em vez disso, você só deve considerar tornar seu projeto de código aberto se o código aberto realmente resolver os desafios que você quer enfrentar (por exemplo, personalização, auto-hospedagem). Se você estiver avaliando esse caminho, vale entender como projetos de código aberto fazem a transição para modelos de código fechado e o que impulsiona essas decisões ao longo do tempo.
Por exemplo, você poderia construir uma alternativa de código aberto ao Twitter, mas é improvável que isso decole, porque redes sociais não se beneficiam muito de ser de código aberto. Há muitos casos de projetos que são de código aberto só por serem de código aberto.
No entanto, se você olhasse por exemplo para o setor de e-commerce, que é majoritariamente dominado por produtos SaaS como Shopify ou BigCommerce, poderia ver que ter uma alternativa de código aberto permitiria que as lojas fossem auto-hospedadas, totalmente personalizadas e com marca branca, além de expandidas de maneiras que não são possíveis com um produto de código fechado. Este seria um bom exemplo de por que você deveria tornar seu projeto de código aberto.
Além disso, com qualquer software aberto, acessível e gratuito, existem desvantagens óbvias e não óbvias. O código aberto tem muitas vantagens, das quais você provavelmente já sabe, mas o código aberto não está livre de desvantagens.
Monetização
Software comercial de código aberto (COSS) é um modelo de empresa em alta em que o produto principal é de código aberto, mas você também tem ofertas comerciais que geram receita. Esses tipos de empresas podem crescer de forma incrível. É da natureza do software livre e aberto ter uma adoção massiva desde cedo. Desenvolvedores adoram código aberto. Eles adoram poder olhar a base de código, corrigir bugs simples que podem incomodar, ou no geral apenas ajudar e retribuir. Quem não gosta de ser útil?
Mas o crescimento massivo e a criação de valor vêm com um custo: captura de valor. Praticamente todo fundador de COSS com quem converso está pensando no conceito de criação de valor e captura de valor.
Um negócio SaaS freemium tem dois clientes: o nível gratuito e o pago. E a proporção geralmente é muito boa. Por exemplo:
“O Webflow alimenta mais de 100.000 sites para empresas grandes e pequenas.” – https://webflow.com/customers
A avaliação mais recente do Webflow foi divulgada como sendo de $2.1B.
Uma empresa de código aberto, por outro lado, parece fundamentalmente diferente, com uma tonelada de pessoas auto-hospedando e clientes gratuitos, que às vezes nem sabem que existe uma empresa comercial por trás do projeto.
Por exemplo: o WordPress alimenta mais de 455 milhões de sites em 2021, e esse número só continua crescendo.
“A empresa-mãe do WordPress.com, Tumblr e outros, a Automattic, anuncia uma nova rodada de captação que leva a avaliação total da empresa para $7.5 bilhões” – https://cheddar.com/media/automattic-announces-288-million-funding-round
Se o Webflow alimentasse 455 milhões de sites — ou — se o WordPress fosse um negócio SaaS centralizado com a economia e o mecanismo de captura de valor do Webflow, provavelmente seriam as maiores empresas do mundo.
Ser uma startup COSS é, essencialmente, jogar o jogo longo. Você não vai capturar receita de pessoas que auto-hospedam seu produto por conta própria, mas espera que a tração do código aberto coloque você no radar de grandes empresas que podem fechar um contrato maior com você.
Por isso, pensar na pista financeira que sua empresa tem é importante. Provavelmente vai levar muito tempo para lançar sua empresa, levar o produto a um estado em que ele seja competitivo com alternativas de código fechado, depois começar a construir tração e, por fim, começar a fechar grandes contratos. Isso significa que, se você não tiver financiamento para continuar trabalhando no produto enquanto ele gera pouca receita no início, talvez não consiga capturar valor suficiente para sobreviver.
Contribuições
Um dos benefícios significativos de ser de código aberto são as contribuições da comunidade. Recebemos algumas contribuições incríveis da comunidade pelas quais somos imensamente gratos. Algumas delas são pequenas correções de bugs, mas outras podem ser recursos enormes.
Normalmente, se pessoas dentro de uma empresa estendem a Cal.com para suas próprias necessidades, por exemplo para escrever uma integração com o Microsoft Exchange, elas provavelmente vão colocar esse código em um pull request para que possamos ter essa funcionalidade dentro do próprio projeto.
A maioria dos engenheiros da nossa equipe anteriormente eram pessoas que contribuíram para o projeto no tempo livre delas, o que funciona muito bem para nós porque conseguimos ver exemplos do trabalho delas imediatamente, elas já estão familiarizadas com a base de código e já têm paixão por trabalhar no projeto.
Roubo
Uma das grandes desvantagens do código aberto é que, com seu código disponível gratuitamente na internet, pessoas vão criar cópias do seu produto e roubar seu código.
Apesar de sermos licenciados sob AGPL e de quaisquer modificações no código terem que ser tornadas de código aberto, ainda há pessoas que fazem e continuarão a violar essas licenças. Além disso, nada impede que um de nossos concorrentes olhe nosso código e veja como construímos recursos, e depois pegue esse código para usar no próprio projeto de código fechado. Se eles fizerem isso bem o suficiente, ninguém vai saber que foi roubado, já que os produtos deles são de código fechado.
Não há muito que realmente possamos fazer para impedir isso. Por isso, tentamos enfrentar a questão das cópias da Cal.com simplesmente tendo uma marca forte e de destaque. Esperamos que, se alguém pegasse o código da Cal.com e criasse a própria versão pirata, não ganhasse tração porque as pessoas saberiam que é uma cópia, e que a comunidade nos avisaria para que possamos tomar medidas legais.
Por exemplo, o código-fonte da Twitch foi comprometido em 2021, mas se você tentasse pegar o código-fonte deles e começar uma versão pirata da Twitch, não chegaria a lugar nenhum.
Então, devo tornar X de código aberto?
Se você está se fazendo essa pergunta, provavelmente não deveria fazer isso. Como mencionamos acima, geralmente fica muito óbvio se você precisa ou não de uma solução aberta, acessível e extensível. Se você não precisa disso, não torne seu projeto de código aberto só por fazer.
No entanto, se você quer vender para o setor enterprise, setores altamente regulados ou apenas quer construir uma solução para as massas (455M WordPress vs 100.000 sites Webflow), então tornar algo de código aberto faz muito sentido.
Além disso, certifique-se de focar em construir o melhor produto. A maioria dos consumidores realmente não se importa se você é de código aberto ou não.
Eles se importam com o melhor valor pelo dinheiro deles. O código aberto ajuda muito na criação de valor: o ciclo de feedback é super rápido, membros da comunidade corrigem bugs, ajudam com traduções e muitas outras coisas, mas nunca se esqueça de construir um produto superior ao do seu concorrente SaaS.
Porque, no fim das contas, é só isso que importa: construir algo de que as pessoas precisem. Se você estiver interessado em como nosso pensamento sobre código aberto continua evoluindo, leia uma mensagem do nosso fundador sobre o nosso próximo capítulo.