Código aberto: o que pensamos?

Código aberto: o que achamos?

Desde o lançamento da Cal.com, recebemos inúmeras mensagens de fundadores a perguntar se o código aberto seria a direção certa para a sua startup e, por isso, queríamos escrever sobre o processo de tomada de decisão de iniciar a cal.com como uma empresa de código aberto, para ajudar outros a tomar uma decisão semelhante.

Tem havido muito mediatismo em torno do código aberto desde 2021, e algumas revistas de tecnologia estão a escrever sobre o "Renascimento do Código Aberto", mas queremos garantir que está a fazer as coisas certas pelas razões certas – ou pelo menos refletir sobre as suas razões.

Temos recebido variações semelhantes da pergunta acima com frequência ultimamente (devido ao crescimento e cobertura do cal.com), razão pela qual queríamos escrever um artigo a delinear a nossa visão sobre SaaS vs código aberto e quando optar pelo código aberto.

Apesar de ambos termos utilizado muitos projetos de código aberto antes e de apreciarmos imenso o trabalho que fazem, nenhum de nós se consideraria um fã incondicional de código aberto. A Cal.com é o primeiro projeto de código aberto no qual qualquer um de nós trabalhou, já que todos os projetos em que tínhamos trabalhado antes eram de código fechado. Na maioria das vezes, havia uma razão muito boa para esses projetos não serem de código aberto.

Antes de mais, por que criámos a Cal.com?

Quando o Peer trabalhou na sua empresa anterior, leanhire.com, percebeu que precisava urgentemente de uma ferramenta de agendamento mais poderosa.

Ao contrário do caso de uso típico onde o Peer, ou os seus funcionários, faziam marcações (como em vendas ou recrutamento), eles precisavam de um produto de agendamento para o seu marketplace de contratações. Em qualquer marketplace de duas vertentes, os seus utilizadores interagem com outros utilizadores, o que não se enquadra bem no modelo típico oferecido pelos produtos de agendamento existentes.

Ferramentas de agendamento como o Calendly, SavvyCal e Motion são produtos incríveis para o ajudar a fazer marcações. No entanto, não têm a capacidade de fornecer a infraestrutura de agendamento para casos de uso mais avançados, tais como marketplaces de contratação, telessaúde e outros. Por exemplo, não seria viável para um marketplace de contratação pagar $19/mês por cada utilizador se tivesse mais de 5.000 utilizadores, como o Peer tinha no Lean Hire.

Os produtos SaaS de agendamento existentes também não fornecem muitas informações sobre o que está a acontecer no interior. Na integração para o Lean Hire, eles pediam anteriormente aos seus clientes para simplesmente copiarem/colarem a sua hiperligação de agendamento e a plataforma adicionava-a automaticamente aos e-mails de divulgação. No entanto, assim que o destinatário clicava na hiperligação de agendamento, a plataforma do Lean Hire não tinha capacidade de monitorizar o que acontecia a seguir.

Eles não sabiam se ou quando os eventos aconteciam, e se eram reagendados ou cancelados. Não havia forma de alterar o fluxo de trabalho de marcação, o design ou as chamadas de API que são feitas no momento da reserva. Assim, era necessária uma solução aberta, acessível e extensível que pudessem alojar por conta própria.

O Peer pesquisou imediatamente no Google por "Calendly open source" porque é isso que o código aberto representa: aberto, acessível, extensível e auto-alojável.

Para sua surpresa, não conseguiu encontrar um único projeto que fizesse o que o Lean Hire procurava. Por coincidência, nesta altura, centenas de outras pessoas procuravam exatamente o mesmo. Foram abertos tópicos em fóruns, discussões no Reddit e muito mais por pessoas que perguntavam se existia um produto de agendamento de código aberto que pudesse rivalizar com as soluções SaaS mais populares.

Por que tornámos a Cal.com um projeto de código aberto?

Desde o primeiro dia, foi ó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 pelo código aberto. Muitos fundadores seguem o caminho errado de pensar que devem construir uma alternativa de código aberto a um produto existente, julgando que o seu produto terá sucesso apenas por ser de código aberto. Em vez disso, só deve considerar tornar o seu projeto de código aberto se o código aberto realmente resolver os desafios que deseja abordar (por exemplo, personalização, auto-alojamento). Se estiver a avaliar este caminho, vale a pena compreender como os projetos de código aberto transitam para modelos de código fechado e o que impulsiona essas decisões ao longo do tempo.

Por exemplo, poderia construir uma alternativa de código aberto ao Twitter, mas é improvável que tivesse sucesso, porque as redes sociais não beneficiam realmente por serem de código aberto. Existem muitos exemplos de projetos que são de código aberto apenas por serem de código aberto.

No entanto, se olhasse, por exemplo, para a indústria do comércio eletrónico, que é maioritariamente dominada por produtos SaaS como a Shopify ou a BigCommerce, conseguiria ver que ter uma alternativa de código aberto permitiria que as lojas fossem alojadas por conta própria, totalmente personalizadas e em marca branca, e estendidas de formas que não são possíveis com um produto de código fechado. Este seria um bom exemplo de por que deve tornar o 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 provavelmente já tem conhecimento, mas o código aberto não deixa de ter as suas desvantagens.

Monetização

O software comercial de código aberto (COSS) é um modelo de empresa em tendência onde o seu produto principal é de código aberto, mas também tem ofertas comerciais que geram receita. Estes tipos de empresas podem ter um crescimento incrível. É da natureza do software livre e aberto ter uma adoção massiva logo no início. Os desenvolvedores adoram o código aberto. Adoram poder analisar a base de código, corrigir pequenos erros que os possam incomodar ou, no geral, ser úteis e dar algo de volta. Quem não gosta de ser útil?

Mas o crescimento massivo e a criação de valor têm um custo: a captura de valor. Praticamente todos os fundadores de COSS com quem falo pensam no conceito de criação de valor e captura de valor.

Um negócio SaaS freemium tem dois tipos de clientes: os de nível gratuito e os pagos. E a proporção é geralmente muito boa. Por exemplo:

“O Webflow suporta mais de 100.000 websites para empresas grandes e pequenas." – https://webflow.com/customers

A avaliação mais recente do Webflow é de $2,1 mil milhões.

Uma empresa de código aberto, por outro lado, parece fundamentalmente diferente, com uma infinidade de utilizadores em auto-alojamento e clientes gratuitos, que por vezes nem sabem que existe uma empresa comercial por trás do projeto.

Por exemplo: o WordPress suporta mais de 455 milhões de websites em 2021, e esse número continua a crescer.

“A empresa-mãe do WordPress.com, Tumblr e outras, Automattic, anuncia uma nova ronda de financiamento elevando 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 suportasse 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, seriam provavelmente as maiores empresas do mundo.

Ser uma startup COSS é essencialmente jogar a longo prazo. Não irá capturar receita de pessoas que alojam o seu produto por conta própria, mas espera que a tração do código aberto o coloque no radar de grandes empresas que possam assinar um contrato maior consigo.

Por isso, pensar no fundo de maneio que a sua empresa tem é importante. É provável que demore muito tempo a lançar a sua empresa, a construir o produto até um estado em que seja competitivo com as alternativas de código fechado, depois a começar a ganhar tração e, finalmente, a começar a fechar grandes negócios. Isto significa que, se não tiver o financiamento para continuar a trabalhar no produto enquanto este gera pouca receita inicialmente, poderá não capturar valor suficiente para sobreviver.

Contribuições

Um dos benefícios significativos de ser código aberto são as contribuições da comunidade. Tivemos algumas contribuições incríveis da comunidade pelas quais estamos incrivelmente gratos. Algumas delas são pequenas correções de erros, mas outras podem ser funcionalidades enormes.

Normalmente, se os colaboradores de uma empresa expandem a Cal.com para as suas próprias necessidades, por exemplo para escrever uma integração com o Microsoft Exchange, eles colocam esse código num pedido de integração (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 tempo livre, o que funciona muito bem para nós porque conseguimos ver exemplos do seu trabalho imediatamente, eles já estão familiarizados com a base de código e já têm paixão por trabalhar no projeto.

Roubo

Uma das maiores desvantagens do código aberto é que, com o seu código disponível gratuitamente na internet, as pessoas criarão imitações do seu produto e roubarão o seu código.

Apesar de estarmos sob licença AGPL e de quaisquer modificações do código terem de ser de código aberto, continuam a existir pessoas que violam e continuarão a violar estas licenças. Além disso, nada impede um dos nossos concorrentes de examinar o nosso código para ver como construímos determinadas funcionalidades e depois utilizar esse código no seu próprio projeto de código fechado. Se fizerem um trabalho bom o suficiente, ninguém saberá que foi roubado, uma vez que os seus produtos são de código fechado.

Não há nada que possamos realmente fazer para impedir isto. Por isso, tentámos abordar o problema de imitações da Cal.com simplesmente tendo uma marca proeminente e forte. Esperamos que, se alguém pegar no código da Cal.com e criar a sua própria versão de imitação, não ganhe tração porque as pessoas sabem que se trata de uma imitação, e que a comunidade nos reporte a situação para podermos tomar medidas legais.

Por exemplo, o código-fonte da Twitch foi comprometido em 2021, mas se tentasse pegar no código-fonte deles e iniciar uma versão de imitação da Twitch, não chegaria a lado nenhum.

Então, devo tornar "X" de código aberto?

Se está a fazer esta pergunta a si próprio, provavelmente não o deve fazer. Como mencionámos acima, geralmente é muito óbvio se precisa de uma solução aberta, acessível e extensível ou não. Se não precisa dela – não a torne de código aberto apenas por fazer.

No entanto, se quer vender para o mercado enterprise, indústrias altamente reguladas ou simplesmente quer construir uma solução para uma enorme quantidade de pessoas (455M de websites em WordPress vs 100.000 em Webflow), então optar pelo código aberto faz todo o sentido.

Adicionalmente, certifique-se de que se foca em construir o melhor produto. A maioria dos consumidores não quer saber se é de código aberto ou não.

Eles importam-se em obter o melhor valor pelo seu dinheiro. O código aberto ajuda imenso na criação de valor: o ciclo de feedback é super rápido, os membros da comunidade corrigem erros, ajudam com traduções e muitas outras coisas, mas nunca se esqueça de construir um produto superior ao do seu concorrente SaaS.

Porque, ao fim ao cabo, é isso que importa: construir algo de que as pessoas precisem. Se está interessado em saber como o nosso pensamento em torno do código aberto continua a evoluir, leia uma mensagem do nosso fundador sobre o nosso próximo capítulo.

A Cal.com é agora GRATUITA para particulares - registe-se aqui