Open source : que pensons-nous ?

Open source : qu’en pensons-nous ?

Depuis le lancement de Cal.com, nous avons reçu d’innombrables messages de fondateurs nous demandant si l’open source serait la bonne direction à prendre pour leur startup, et nous voulions donc écrire sur le processus de décision qui nous a conduits à créer cal.com en tant qu’entreprise open source, afin d’aider d’autres personnes à prendre une décision similaire.

Il y a eu beaucoup d’engouement autour de l’open source depuis 2021, et certains magazines tech écrivent sur la "Renaissance de l’Open Source", mais nous voulons nous assurer que vous faites les bonnes choses pour les bonnes raisons – ou au moins réfléchir à vos raisons.

Nous avons récemment reçu assez souvent des variations similaires à la question ci-dessus (en raison de la croissance et de la couverture médiatique de cal.com), c’est pourquoi nous voulions rédiger un article expliquant notre façon de voir le SaaS par rapport à l’open source et le moment opportun pour passer en open source.

Bien que nous ayons tous les deux utilisé de nombreux projets open source auparavant et énormément apprécié le travail qu’ils accomplissent, aucun de nous ne se considérerait comme un fan inconditionnel de l’open source. Cal.com est le premier projet OSS sur lequel l’un ou l’autre de nous ait travaillé, car tous les projets sur lesquels nous avions travaillé auparavant étaient en source fermée. La plupart du temps, il y avait une très bonne raison pour laquelle ces projets n’étaient pas open source.

Pourquoi avons-nous construit Cal.com dès le départ ?

Lorsque Peer travaillait sur son entreprise précédente, leanhire.com, il a constaté qu’elle avait désespérément besoin d’un outil de planification plus puissant.

Contrairement au cas d’usage typique où Peer, ou ses employés, effectueraient des réservations (comme dans la vente ou le recrutement), ils avaient besoin d’un produit de planification pour leur place de marché de recrutement. Dans toute place de marché à deux faces, vos utilisateurs interagissent avec d’autres utilisateurs, ce qui ne correspond pas bien au modèle classique proposé par les produits de planification existants.

Les outils de planification comme Calendly, SavvyCal et Motion sont d’excellents produits pour vous aider à prendre des rendez-vous. Cependant, ils n’ont pas la capacité de fournir l’infrastructure de planification pour des cas d’usage plus avancés, tels que les places de marché de recrutement, la télésanté, et bien plus encore. Par exemple, il ne serait pas viable pour une place de marché de recrutement de payer 19 $/mois pour chaque siège si vous avez plus de 5 000 utilisateurs, comme Peer en avait chez Lean Hire.

Les produits SaaS de planification existants ne fournissent pas non plus beaucoup d’informations sur ce qui se passe en interne. Lors de l’onboarding chez Lean Hire, ils demandaient auparavant à leurs clients de simplement copier/coller leur lien de planification et la plateforme l’ajoutait automatiquement aux e-mails de prospection. Cependant, une fois que le destinataire cliquait sur le lien de planification, la plateforme Lean Hire n’avait aucun moyen de suivre ce qui se passait ensuite.

Ils ne savaient pas si des événements avaient eu lieu, ni quand, ni s’ils avaient été reprogrammés ou annulés. Il n’y avait aucun moyen de modifier le workflow de réservation, la conception ou les appels API effectués lors de la réservation. Il fallait donc une solution ouverte, accessible, extensible et pouvant être auto-hébergée.

Peer a immédiatement recherché sur Google "Calendly open source" parce que c’est ce que l’open source signifie : ouvert, accessible, extensible et auto-hébergeable.

À sa surprise, il n’a pas pu trouver un seul projet qui fasse ce que Lean Hire recherchait. Incidemment, à ce moment-là, des centaines d’autres personnes recherchaient exactement la même chose. Des fils de discussion sur des forums, des débats sur Reddit et bien d’autres choses encore ont été ouverts par des personnes se demandant s’il existait un produit de planification open source pouvant rivaliser avec les solutions SaaS les plus populaires.

Pourquoi avons-nous rendu Cal.com open source ?

Dès le premier jour, il nous a semblé évident que Cal.com serait un projet open source. Ce que nous avions l’intention de faire était fondamentalement plus difficile en tant que produit SaaS fermé qu’en tant que projet open source.

Le point clé ici est que les limites des produits de planification existants ne pouvaient être résolues que par l’open source. Beaucoup de fondateurs s’engagent dans la mauvaise direction en pensant qu’ils devraient créer une alternative open source à un produit existant, en pensant que leur produit réussirait uniquement parce qu’il est open source. À la place, vous ne devriez envisager de rendre votre projet open source que si l’open source résout réellement les défis que vous souhaitez relever (par exemple la personnalisation, l’auto-hébergement). Si vous évaluez cette voie, il vaut la peine de comprendre comment les projets open source passent à des modèles source fermée et ce qui motive ces décisions au fil du temps.

Par exemple, vous pourriez créer une alternative Twitter open source, mais il est peu probable qu’elle décolle, car les réseaux sociaux ne bénéficient pas vraiment du fait d’être open source. Il existe de nombreux exemples de projets qui sont open source simplement pour être open source.

En revanche, si vous regardiez par exemple le secteur du commerce électronique, qui est largement dominé par des produits SaaS comme Shopify ou BigCommerce, vous pourriez constater qu’avoir une alternative open source permettrait aux boutiques d’être auto-hébergées, entièrement personnalisées et en marque blanche, et étendues d’une manière impossible avec un produit source fermée. Ce serait un bon exemple de la raison pour laquelle vous devriez rendre votre projet open source.

En plus de cela, avec tout logiciel ouvert, accessible et gratuit, il existe des inconvénients évidents et moins évidents. L’open source présente de nombreux avantages dont vous avez probablement conscience, mais l’open source n’est pas sans inconvénients.

Monétisation

Le logiciel commercial open source (COSS) est un modèle d’entreprise en vogue dans lequel votre produit principal est open source, mais vous avez également des offres commerciales qui génèrent des revenus. Ces types d’entreprises peuvent connaître une croissance incroyable. C’est dans la nature du logiciel libre et ouvert d’être massivement adopté très tôt. Les développeurs aiment l’open source. Ils aiment pouvoir examiner le code, corriger les bogues simples qui peuvent les gêner, ou tout simplement être utiles et rendre quelque chose en retour. Qui n’aime pas être utile ?

Mais cette croissance massive et cette création de valeur ont un coût : la capture de valeur. À peu près tous les fondateurs COSS avec qui je parle réfléchissent au concept de création de valeur et de capture de valeur.

Une entreprise SaaS freemium a deux clients : le niveau gratuit et le niveau payant. Et le ratio est généralement très bon. Par exemple :

“Webflow alimente plus de 100 000 sites web pour des entreprises grandes et petites." – https://webflow.com/customers

La dernière valorisation de Webflow serait de 2,1 milliards de dollars.

Une entreprise open source, en revanche, se présente fondamentalement différemment, avec une foule d’utilisateurs auto-hébergeurs et de clients gratuits, qui parfois ne savent même pas qu’une entreprise commerciale se cache derrière le projet.

Par exemple : WordPress alimente plus de 455 millions de sites web en 2021, et ce nombre continue seulement de croître.

“La société mère de WordPress.com, Tumblr et d’autres, Automattic, annonçant un nouveau tour de financement portant la valorisation totale de l’entreprise à 7,5 milliards de dollars” – https://cheddar.com/media/automattic-announces-288-million-funding-round

Si Webflow alimentait 455 millions de sites web – ou – si WordPress était une entreprise SaaS centralisée avec l’économie et le mécanisme de capture de valeur de Webflow, elles seraient probablement les plus grandes entreprises du monde.

Être une startup COSS, c’est essentiellement jouer sur le long terme. Vous ne capturerez pas de revenus auprès des personnes qui auto-hébergent votre produit chez elles, mais vous espérez que la traction de l’open source vous mette sur le radar de grandes entreprises qui pourraient conclure un accord plus important avec vous.

Par conséquent, il est important de réfléchir à la marge de manœuvre dont dispose votre entreprise. Il faudra probablement beaucoup de temps pour lancer votre entreprise, développer le produit jusqu’à un niveau où il est compétitif avec les alternatives source fermée, puis commencer à générer de la traction et enfin à conclure de gros contrats. Cela signifie que si vous n’avez pas le financement nécessaire pour continuer à travailler sur le produit alors qu’il génère peu de revenus au départ, vous risquez de ne pas capturer suffisamment de valeur pour survivre.

Contributions

L’un des avantages significatifs d’être open source est la contribution de la communauté. Nous avons reçu d’incroyables contributions de la communauté, pour lesquelles nous sommes extrêmement reconnaissants. Certaines sont de petites corrections de bogues, mais d’autres peuvent être de grandes fonctionnalités.

Habituellement, si des personnes au sein d’une entreprise étendent Cal.com pour leurs propres besoins, par exemple pour écrire une intégration Microsoft Exchange, elles mettront probablement ce code dans une pull request afin que nous puissions avoir cette fonctionnalité dans le projet lui-même.

La plupart des ingénieurs de notre équipe étaient auparavant des personnes qui contribuaient au projet sur leur temps libre, ce qui nous convient très bien parce que nous pouvons voir tout de suite des exemples de leur travail, ils sont déjà familiers avec la base de code, et ils ont déjà une passion pour travailler sur le projet.

Vol

L’un des principaux inconvénients de l’open source est qu’avec votre code librement disponible sur Internet, des personnes créeront des copies frauduleuses de votre produit et voleront votre code.

Malgré le fait que nous soyons sous licence AGPL et que toute modification du code doive être open source, il y a toujours des personnes qui enfreignent et continueront d’enfreindre ces licences. De plus, rien n’empêche l’un de nos concurrents d’examiner notre code et de voir comment nous avons construit les fonctionnalités, puis de prendre ce code pour l’utiliser dans leur propre projet source fermée. S’ils font cela suffisamment bien, personne ne saura que cela a été volé, puisque leurs produits sont en source fermée.

Nous ne pouvons vraiment rien faire pour l’empêcher. Par conséquent, nous essayons de traiter le problème des copies de Cal.com simplement en ayant une marque forte et bien visible. Nous espérons que si quelqu’un prenait le code de Cal.com pour créer sa propre copie, cela ne gagnerait aucune traction, car les gens sauraient que c’est une copie, et que la communauté nous le signalerait afin que nous puissions engager des poursuites judiciaires.

Par exemple, le code source de Twitch a été compromis en 2021, mais si vous essayiez de prendre leur code source et de lancer une copie de Twitch, vous n’iriez nulle part.

Alors, dois-je open source X ?

Si vous vous posez cette question, vous ne devriez probablement pas le faire. Comme nous l’avons mentionné ci-dessus, il est généralement très évident de savoir si vous avez besoin ou non d’une solution ouverte, accessible et extensible. Si vous n’en avez pas besoin, n’ouvrez pas votre code source juste pour le principe.

Cependant, si vous souhaitez vendre à des entreprises, à des secteurs fortement réglementés ou si vous voulez simplement créer une solution pour les masses de personnes (455 M WordPress contre 100 000 sites Web Webflow), alors passer en open source a énormément de sens.

De plus, assurez-vous de vous concentrer sur la création du meilleur produit. La majorité des consommateurs ne se soucient pas vraiment que vous soyez open source ou non.

Ils se soucient du meilleur rapport qualité-prix. L’open source aide énormément à créer de la valeur : le cycle de retour est ultra rapide, les membres de la communauté corrigent des bogues, aident à la traduction, et font beaucoup d’autres choses, mais n’oubliez jamais de construire un produit supérieur à celui de votre concurrent SaaS.

Car au bout du compte, c’est tout ce qui compte : construire quelque chose dont les gens ont besoin. Si vous souhaitez comprendre comment notre réflexion sur l’open source continue d’évoluer, lisez un message de notre fondateur sur notre prochain chapitre.

Cal.com est désormais GRATUIT pour les particuliers - inscrivez-vous ici