Open source: o que achamos?
Open source: o que achamos?
Desde o lançamento da Cal.com, recebemos inúmeras mensagens de fundadores a perguntar se o open source seria a direção certa para a sua startup seguir, e por isso quisemos escrever sobre o processo de decisão de começar a cal.com como uma empresa de open source, para ajudar outras pessoas a tomar uma decisão semelhante.
Tem havido muito entusiasmo em torno do open source desde 2021, e algumas revistas de tecnologia estão a escrever sobre o "Renascimento do Open Source", mas queremos garantir que estás a fazer as coisas certas pelos motivos certos — ou pelo menos refletir sobre os teus motivos.
Temos recebido recentemente bastantes variações semelhantes da pergunta acima (devido ao crescimento e à cobertura da cal.com), e é por isso que quisemos escrever um post a explicar como pensamos em SaaS vs open source e quando optar por open source.
Apesar de ambos termos usado muitos projetos de open source antes e de termos valorizado imenso o trabalho que fazem, nenhum de nós se consideraria um fã incondicional de open source. A Cal.com é o primeiro projeto OSS em que qualquer um de nós trabalhou, já que todos os projetos em que trabalhámos antes eram closed source. Na maior parte do tempo havia uma razão muito boa para esses projetos não serem open source.
Porque é que construímos a Cal.com, antes de mais?
Quando o Peer trabalhou na sua empresa anterior, a leanhire.com, percebeu que esta precisava urgentemente de uma ferramenta de agendamento mais poderosa.
Ao contrário do caso de uso típico em que o Peer, ou os seus colaboradores, fariam bookings (como em vendas ou recrutamento), eles precisavam de um produto de agendamento para o seu marketplace de contratação. Em qualquer marketplace de dois lados, os teus utilizadores interagem com outros utilizadores, o que não 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 te ajudar a fazer bookings. No entanto, não têm a capacidade de fornecer a infraestrutura de agendamento para casos de uso mais avançados, como marketplaces de contratação, telehealth e muito mais. Por exemplo, não seria viável para um marketplace de contratação pagar $19/mês por cada posto se tiveres mais de 5.000 utilizadores, como o Peer tinha na Lean Hire.
Os produtos SaaS de agendamento existentes também não dão muitas perspetivas sobre o que se passa lá dentro. No onboarding da Lean Hire, antes pediam aos clientes para simplesmente copiar/colar o seu scheduling link e a plataforma adicionava-o automaticamente aos emails de outreach. No entanto, assim que o destinatário clicava no scheduling link, a plataforma da Lean Hire não tinha capacidade para acompanhar o que acontecia a seguir.
Eles não sabiam se os eventos aconteciam nem quando, nem se eram reagendados ou cancelados. Não havia forma de alterar o fluxo de trabalho de booking, o design ou as chamadas de API que são feitas durante o booking. Assim, era necessária uma solução aberta, acessível e extensível que pudessem self-host.
O Peer pesquisou imediatamente no Google por "Calendly open source" porque é isso que o open source significa: aberto, acessível, extensível e self-hostable.
Para sua surpresa, não conseguiu encontrar um único projeto a fazer o que a Lean Hire procurava. E, curiosamente, nessa altura centenas de outras pessoas estavam a procurar exatamente a mesma coisa. Foram criados tópicos em fóruns, discussões no Reddit e muito mais por pessoas a perguntar se existia um produto de agendamento open-source que pudesse rivalizar com as soluções SaaS mais populares.
Porque é que tornámos a Cal.com open source?
Desde o primeiro dia, foi óbvio para nós que a Cal.com seria um projeto de open source. As coisas que queríamos fazer eram fundamentalmente mais difíceis enquanto produto SaaS fechado do que sendo open source.
O ponto-chave aqui é que as limitações dos produtos de agendamento existentes só podiam ser resolvidas com open source. Muitos fundadores seguem o caminho errado ao pensar que devem construir uma alternativa open source a um produto existente, acreditando que o seu produto terá sucesso apenas porque é open source. Em vez disso, só deves considerar tornar o teu projeto open source se o open source realmente resolver os desafios que queres enfrentar (por exemplo, personalização, self-hosting). Se estiveres a avaliar este caminho, vale a pena perceber como os projetos open source transitam para modelos closed source e o que motiva essas decisões ao longo do tempo.
Por exemplo, podias construir uma alternativa open source ao Twitter, mas é pouco provável que ela ganhasse tração, porque as redes sociais não beneficiam realmente de ser open source. Há muitos casos de projetos que são open source apenas pelo facto de serem open source.
No entanto, se olhasses, por exemplo, para a indústria do e-commerce, que é maioritariamente dominada por produtos SaaS como Shopify ou BigCommerce, poderias ver que ter uma alternativa open source permitiria que as lojas fossem self-hosted, totalmente personalizadas e whitelabeled, e estendidas de formas que não são possíveis com um produto closed source. Este seria um bom exemplo de por que deves tornar o teu projeto open source.
Além disso, com qualquer software aberto, acessível e gratuito, há desvantagens óbvias e outras nem tanto. O open source tem muitas vantagens das quais provavelmente já tens noção, mas o open source não está isento de desvantagens.
Monetização
O software comercial de open source (COSS) é um modelo de empresa em tendência em que o teu produto principal é open source, mas também tens ofertas comerciais que geram receita. Estes tipos de empresas podem ter um crescimento incrível. É natural do software gratuito e aberto ter uma adoção massiva logo no início. Os developers adoram open source. Adoram poder olhar para o codebase, corrigir bugs simples que os possam incomodar, ou simplesmente ser úteis e retribuir. Quem é que 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 quem falo estão a pensar 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 costuma ser muito boa. Por exemplo:
“O Webflow alimenta mais de 100.000 websites para empresas grandes e pequenas." – https://webflow.com/customers
A avaliação mais recente do Webflow foi reportada como sendo de $2.1B.
Uma empresa de open source, por outro lado, parece fundamentalmente diferente, com imensos self-hosters e clientes gratuitos, que por vezes nem sequer sabem que existe uma empresa comercial por trás do projeto.
Por exemplo: o WordPress alimenta mais de 455 milhões de websites em 2021, e esse número continua apenas a crescer.
“A empresa-mãe de WordPress.com, Tumblr e muito mais, a Automattic, anuncia uma nova ronda de financiamento que eleva a avaliação total da empresa para $7.5 mil milhões” – https://cheddar.com/media/automattic-announces-288-million-funding-round
Se o Webflow alimentasse 455 milhões de websites — 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 a longo prazo. Não vais capturar receita de pessoas que fazem self-host do teu produto por conta própria, mas esperas que a tração do open source te coloque no radar de grandes empresas que possam fechar contigo um contrato maior.
Por isso, é importante pensar no runway que a tua empresa tem. Provavelmente vai demorar muito tempo a lançar a tua empresa, a desenvolver o produto até um estado em que seja competitivo com alternativas closed source, depois começar a ganhar tração e, finalmente, a fechar grandes negócios. Isto significa que, se não tiveres financiamento para continuar a trabalhar no produto enquanto ele gera pouca receita no início, talvez não consigas capturar valor suficiente para sobreviver.
Contribuições
Uma das vantagens significativas de ser open source são as contribuições da comunidade. Tivemos algumas contribuições incríveis da comunidade pelas quais estamos imensamente gratos. Algumas são pequenas correções de bugs, mas outras podem ser funcionalidades enormes.
Normalmente, se pessoas dentro de uma empresa estendem a Cal.com para as suas próprias necessidades, por exemplo para escrever uma integração com Microsoft Exchange, provavelmente vão colocar esse código num pull request para que possamos ter essa funcionalidade dentro do próprio projeto.
A maioria dos engenheiros da nossa equipa eram anteriormente pessoas que contribuíam para o projeto no seu próprio tempo, o que funciona muito bem para nós porque podemos ver exemplos do seu trabalho logo de início, já estão familiarizados com a codebase, e já têm uma paixão por trabalhar no projeto.
Roubar
Uma das grandes desvantagens do open source é que, com o teu código disponível gratuitamente na internet, as pessoas vão criar cópias do teu produto e roubar o teu código.
Apesar de estarmos licenciados sob AGPL e de quaisquer modificações ao código terem de ser open sourced, ainda há pessoas que violam e continuarão a violar estas licenças. Além disso, nada impede um dos nossos concorrentes de olhar para o nosso código e ver como construímos funcionalidades, e depois pegar nesse código para o usar no seu próprio projeto closed source. Se fizerem um trabalho suficientemente bom, ninguém saberá que foi roubado, já que os seus produtos são closed source.
Não há nada que possamos realmente fazer para impedir isto. Por isso, tentamos enfrentar a questão das cópias da Cal.com simplesmente através de uma marca forte e muito visível. Esperamos que, se alguém pegar no código da Cal.com e criar a sua própria cópia, não ganhe tração nenhuma, porque as pessoas saberão que se trata de uma cópia, e que a comunidade nos informe para que possamos tomar medidas legais.
Por exemplo, o código-fonte da Twitch foi comprometido em 2021, mas se tentasses pegar no código-fonte deles e lançar uma cópia da Twitch, não ias chegar a lado nenhum.
Então, devo open-source X?
Se estás a fazer esta pergunta, provavelmente não deves fazê-lo. Como mencionámos acima, geralmente é muito óbvio se precisas ou não de uma solução que seja aberta, acessível e extensível. Se não precisas dela — não a tornes open source só por tornar.
No entanto, se queres vender para enterprise, setores altamente regulamentados ou simplesmente queres construir uma solução para as grandes massas de pessoas (455M WordPress vs 100.000 websites Webflow), então tornar open source faz imenso sentido.
Além disso, certifica-te de que te focas em construir o melhor produto. A maioria dos consumidores não quer saber, na verdade, se és open source ou não.
Querem o melhor valor pelo seu dinheiro. O open source ajuda imenso 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 te esqueças de construir um produto superior ao teu concorrente SaaS.
Porque, no fim do dia, é isso que interessa: constrói algo de que as pessoas precisam. Se tiveres interesse em saber como o nosso pensamento sobre open source continua a evoluir, lê uma mensagem do nosso fundador sobre o nosso próximo capítulo.
A Cal.com é agora GRATUITA para indivíduos - inscreve-te aqui