Código aberto: o que pensamos?
Desde o lançamento do Cal.com, recebemos inúmeras mensagens de fundadores perguntando se o código aberto seria a direção certa para suas startups, e por isso quisemos escrever sobre o processo de tomada de decisão de iniciar o cal.com como uma empresa de código aberto, para ajudar outros a tomar uma decisão similar.
Tem havido muito alvoroço 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 pelas razões certas – ou pelo menos refletir sobre suas razões.
Temos recebido variações semelhantes da pergunta acima com bastante frequência recentemente (devido ao crescimento e cobertura do cal.com), razão pela qual quisemos escrever um post destacando como pensamos sobre SaaS vs código aberto e quando abrir código.
Apesar de ambos termos utilizado muitos projetos de código aberto antes e apreciado imensamente o trabalho que eles realizam, nenhum de nós se consideraria um fã ardente do código aberto. O Cal.com é o primeiro projeto de OSS em que ambos trabalhamos, já que todos os projetos em que trabalhamos antes eram de código fechado. Na maioria das vezes, havia uma razão muito boa para que esses projetos não fossem de código aberto.
Por que construímos o Cal.com em primeiro lugar?
Quando o Peer trabalhou em sua empresa anterior, leanhire.com, ele percebeu que havia uma necessidade urgente de uma ferramenta de agendamento mais poderosa.
Diferentemente do caso de uso típico onde o Peer, ou seus funcionários, fariam reservas (como em vendas ou recrutamento), eles precisavam de um produto de agendamento para seu mercado de contratação. Em todo mercado bilatera, seus usuários estão interagindo com outros usuários, o que não se encaixa bem com o modelo típico oferecido pelos produtos de agendamento existentes.
Ferramentas de agendamento como Calendly, SavvyCal e Motion são produtos incríveis para ajudá-lo a fazer reservas. No entanto, eles não têm a capacidade de fornecer a infraestrutura de agendamento para casos de uso de agendamento mais avançados, como mercados de contratação, telemedicina e mais. Por exemplo, não seria viável para um mercado 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.
Os produtos de agendamento SaaS existentes também não oferecem muitos insights sobre o que está acontecendo internamente. No onboarding da Lean Hire, eles anteriormente pediam aos seus clientes que simplesmente copiassem/colassem seu link de agendamento e a plataforma o adicionaria automaticamente aos e-mails de divulgação. No entanto, uma vez que o destinatário clicasse no link de agendamento, a plataforma Lean Hire não tinha a capacidade de rastrear o que acontece a seguir.
Eles não sabiam se ou quando os eventos aconteciam, e se foram reagendados ou cancelados. Não havia como alterar o fluxo de trabalho de reserva, design ou chamadas de API que estão sendo feitas ao reservar. Assim, uma solução aberta, acessível e extensível que pudessem auto-hospedar era necessária.
Peer imediatamente pesquisou no Google por "Calendly código aberto" porque isso é o que código aberto significa: aberto, acessível, extensível e auto-hospedável.
Para sua surpresa, ele não conseguiu encontrar um único projeto fazendo o que a Lean Hire estava procurando. Coincidentemente, nesse momento, centenas de outras pessoas estavam buscando exatamente a mesma coisa. Fios de fórum, discussões no Reddit e mais foram abertos por pessoas perguntando se havia um produto de agendamento de código aberto que pudesse rivalizar com as soluções SaaS mais populares.
Por que fizemos do Cal.com um código aberto?
Desde o primeiro dia, ficou óbvio para nós que o 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 por meio do código aberto. Muitos fundadores seguem o caminho errado pensando que deveriam construir uma alternativa de código aberto para um produto existente, acreditando que seu produto terá sucesso apenas porque é código aberto. Em vez disso, você deve considerar fazer seu projeto de código aberto apenas se o código aberto realmente resolver os desafios que você deseja abordar (por exemplo, personalização, auto-hospedagem).
Por exemplo, você poderia construir uma alternativa ao Twitter de código aberto, mas é improvável que isso decole, porque as redes sociais não se beneficiam realmente de serem de código aberto. Existem muitos casos de projetos que são de código aberto apenas pelo simples fato de serem de código aberto.
No entanto, se você, por exemplo, olhar para a indústria de e-commerce, que é dominada principalmente por produtos SaaS como Shopify ou BigCommerce, poderá ver que ter uma alternativa de código aberto permitiria que as lojas fossem auto-hospedadas, totalmente personalizadas e com marca branca, e estendidas de maneiras que não são possíveis com um produto de código fechado. Este seria um bom caso de por que você deveria abrir o código do seu projeto.
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 está ciente, mas o código aberto não está isento de suas desvantagens.
Monetização
O software comercial de código aberto (COSS) é um modelo de empresa em alta onde seu produto principal é de código aberto, mas você também tem ofertas comerciais que geram receita. Esses tipos de empresas podem ter um crescimento incrível. É da natureza do software livre e aberto ter uma enorme adoção inicialmente. Desenvolvedores adoram código aberto. Eles adoram poder olhar o código-fonte, corrigir bugs simples que podem incomodá-los, ou, no geral, apenas ser útil e dar algo de volta. Quem não gosta de ser útil?
Mas o enorme crescimento e a criação de valor têm um custo: a captura de valor. Praticamente todos os fundadores de COSS com os quais eu converso estão pensando no conceito de criação de valor e captura de valor.
Um negócio SaaS freemium tem dois clientes: camada gratuita e paga. 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 última avaliação do Webflow é relatada em $2,1 bilhões.
Uma empresa de código aberto, por outro lado, parece fundamentalmente diferente, com uma tonelada de auto-hospedadores 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 apenas continua a crescer.
“A empresa mãe do WordPress.com, Tumblr, e mais, Automattic, anunciou uma nova rodada de financiamento que trouxe 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, eles provavelmente seriam as maiores empresas do mundo.
Ser uma startup de COSS é essencialmente jogar o jogo a longo prazo. Você não capturará receita de pessoas que auto-hospedam seu produto sozinhas, mas espera que a tração do código aberto coloque você no radar de grandes empresas que poderiam assinar um contrato maior com você.
Assim, pensar sobre o tempo de duração que sua empresa tem é importante. Provavelmente levará muito tempo para lançar sua empresa, construir o produto até um estado em que seja competitivo com alternativas de código fechado, então começar a ganhar tração e, finalmente, começar a fechar grandes negócios. Isso significa que, se você não tiver o financiamento para continuar trabalhando no produto enquanto ele gera pouca receita inicialmente, pode não 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. Tivemos algumas contribuições incríveis da comunidade pelas quais somos incrivelmente gratos. Algumas delas são pequenos reparos, mas outras podem ser grandes recursos.
Normalmente, se pessoas dentro de uma empresa estendem o Cal.com para suas próprias necessidades, por exemplo, para escrever uma integração com o Microsoft Exchange, elas provavelmente colocarão esse código em uma solicitação de pull para que possamos ter essa funcionalidade dentro do projeto em si.
A maioria dos engenheiros de nossa equipe foram anteriormente pessoas que contribuíram para o projeto em seu próprio tempo, o que funciona muito bem para nós porque podemos ver exemplos de seu trabalho imediatamente, eles já estão familiarizados com a base de código e já têm uma paixão por trabalhar no projeto.
Roubo
Uma das principais desvantagens do código aberto é que com seu código livremente disponível na internet, as pessoas criarão cópias do seu produto e roubarão seu código.
Apesar do fato de estarmos licenciados sob a AGPL e que quaisquer modificações do código devem ser abertas, ainda existem pessoas que fazem e continuarão a violar essas licenças. Além disso, não há nada que impeça um de nossos concorrentes de olhar para nosso código e ver como construímos recursos, e então levar esse código para usar em seu próprio projeto de código fechado. Se eles fizerem um bom trabalho, ninguém saberá que foi roubado, pois seus produtos são de código fechado.
Não há nada que realmente possamos fazer para impedir isso. Assim, tentamos enfrentar o problema de cópias do Cal.com simplesmente tendo uma marca forte e proeminente. Esperamos que, se alguém tomasse o código do Cal.com e criasse sua própria versão de cópia, isso não ganhasse tração, pois as pessoas sabem que é uma cópia, e que a comunidade nos reportaria para que pudéssemos tomar medidas legais.
Por exemplo, o código-fonte do Twitch foi comprometido em 2021, mas se você tentasse pegar o código-fonte deles e começar uma versão de cópia do Twitch, você não conseguiria fazer nada.
Então, devo abrir o código de X?
Se você está se perguntando isso, provavelmente não deve fazê-lo. Como mencionamos acima, geralmente é muito óbvio se você precisa de uma solução que seja aberta, acessível e extensível ou não. Se você não precisa – não abra o código apenas por abrir.
No entanto, se você deseja vender para empresas, indústrias altamente regulamentadas ou apenas quer construir uma solução para as massas (455M WordPress vs 100.000 sites Webflow) então abrir o código faz muito sentido.
Além disso, certifique-se de se concentrar em construir o melhor produto. A maioria dos consumidores não se importa muito se você é de código aberto ou não.
Eles se importam com o melhor valor pelo seu dinheiro. O código aberto ajuda muito na criação de valor: o ciclo de feedback é super rápido, os membros da comunidade corrigem bugs, ajudam com traduções e muitas outras coisas, mas nunca se esqueça de construir um produto superior ao seu concorrente SaaS.
Porque no final do dia, isso é tudo que importa: construir algo que as pessoas precisam.
