Dois-je convertir mon entreprise en open source ? (2022)
(supabase.com)- Supabase a choisi l’open source dès les débuts de l’entreprise, et en construisant son produit publiquement, a obtenu des avantages plus importants que prévu pour la communauté, le recrutement et l’élargissement du produit
- Les inquiétudes les plus fréquentes concernent les critiques sur la qualité du code, l’exposition de failles de sécurité et la copie par des concurrents, mais l’ouverture peut aussi favoriser les améliorations et des itérations rapides
- En recrutement, les contributions au dépôt montrent le vrai code d’un candidat et sa manière de collaborer ; Supabase n’a commencé le recrutement outbound qu’après avoir embauché 32 développeurs
- Les fonctionnalités pour une minorité d’utilisateurs, les intégrations et les adaptateurs peuvent être créés directement par la communauté, ce qui élargit le périmètre du produit et compense les limites de priorisation de l’équipe interne
- La capacité défensive d’une entreprise open source ne vient pas tant du fait de cacher son code que de l’exécution rapide, de la marque, de l’équipe et de la communauté construits sur le long terme
Pourquoi Supabase a choisi l’open source dès le départ
- Supabase a été open source dès le premier jour, et comme ses fondateurs étaient depuis longtemps utilisateurs et soutiens de projets publics comme PostgreSQL, Python, Bitcoin et React, ce choix ne leur a pas semblé particulièrement difficile à l’époque
- Contrairement à l’idée que construire une entreprise publiquement serait très contraignant, plusieurs avantages inattendus sont apparus au fil de la croissance du produit et de l’entreprise
- L’expérience présentée concerne une entreprise d’outils pour développeurs ou de PaaS, mais une grande partie s’applique aussi aux entreprises logicielles en général
- Les inquiétudes récurrentes qui freinent le passage à l’open source sont principalement au nombre de trois
- Des gens pourraient critiquer un code désordonné ou inachevé
- Des hackers pourraient trouver des failles de sécurité et les exploiter
- Des concurrents pourraient voler la propriété intellectuelle
La peur de dire « mon code est mauvais »
- L’angoisse liée au mauvais code relève souvent surtout de l’ego, et si quelqu’un prend le temps de l’examiner, c’est qu’il y a probablement trouvé quelque chose qui mérite qu’on s’y intéresse
- Comme dans l’histoire de la Stone Soup, quand on partage une bonne idée avec la communauté, d’autres peuvent s’en emparer et l’améliorer ensemble
- La communauté peut refactorer ou remplacer du mauvais code, et introduire de nouvelles règles de qualité qui améliorent aussi les futures contributions
- Les membres toxiques qui se contentent de se plaindre du code sans proposer d’amélioration ne sont de toute façon pas le type de communauté recherché
- Les contributeurs open source ont souvent un « cimetière » d’anciens projets, qui devient une bibliothèque d’idées et d’approches pour ceux qui veulent construire quelque chose de similaire
- Quelqu’un peut s’inspirer d’une manière particulière de résoudre un problème
- Au minimum, cela peut faire gagner du temps en évitant de répéter les mêmes erreurs
- Il est plus probable qu’un ancien projet soit utile ou passe inaperçu qu’il ne nuise réellement à la réputation
Code public et sécurité
- Lorsqu’on exploite une solution hébergée à partir d’un code public, la plus grande peur est qu’un acteur malveillant lise le code, découvre une vulnérabilité et pirate le service
- D’après l’expérience de Supabase, la loi de Linus, selon laquelle « avec suffisamment d’yeux, tous les bugs sont superficiels », s’applique aussi aux problèmes de sécurité
- Dès les débuts, des chercheurs en sécurité, souvent anonymes, ont aidé en examinant le code et la plateforme pour y repérer des problèmes potentiels
- Si vous fournissez un SaaS, vous devriez proposer des indications simples dans
/.well-known/security.txtafin que les chercheurs bien intentionnés sachent comment divulguer d’éventuels problèmes - L’exemple donné pour montrer qu’un projet public peut être plus sûr qu’une base de code propriétaire est Bitcoin
- Dans une conférence de 2015, Andreas M. Antonopoulos expliquait que les systèmes bancaires fermés ont, du point de vue logiciel, un système immunitaire faible
- Dans les systèmes fermés, de grosses failles peuvent rester cachées longtemps et provoquer des dégâts majeurs lorsqu’elles sont finalement exploitées
- Dans un protocole open source comme Bitcoin, les failles sont visibles par tous, les exploits sont souvent découverts tôt et régulièrement, puis corrigés
- Comme une entreprise logicielle à succès peut se construire sur plus de 10 ans, un système open source peut à long terme se rapprocher d’un niveau de sécurité supérieur à celui d’un système propriétaire et secret
- À une époque où la concurrence pour recruter d’excellents ingénieurs sécurité est extrêmement forte, la valeur de la relecture publique devient encore plus grande
Les inquiétudes liées aux concurrents et à la propriété intellectuelle
- En logiciel, les idées coûtent peu ; la valeur vient presque toujours de leur exécution
- En partageant ses idées avec le monde, on peut se concentrer sur des itérations plus rapides au lieu de s’inquiéter de savoir qui aura accès à la base de code
-
Construire une communauté d’experts
- Pour bâtir une entreprise solide, il faut bien exécuter pendant une longue période, par exemple 10 ans, tout en développant sa base de clients
- Dans cette course de fond, l’avantage qu’un concurrent tire du fait de consulter la base de code a de fortes chances d’être limité à l’échelle de ces 10 années
- Pendant cette période, la base de code sera probablement itérée et refactorée de nombreuses fois
- À long terme, la manière de gagner consiste à créer l’équipe et la communauté qui améliorent et itèrent le mieux au monde sur leur propre solution
-
Gagner sur le marché
- Si le marché total adressable (TAM) est vaste et en croissance, et vaut réellement la peine d’être poursuivi, il y a peu de chances qu’il s’agisse d’un marché où le gagnant rafle tout
- Il faut d’abord trouver un segment d’utilisateurs que l’on peut réellement enthousiasmer, puis itérer rapidement
- Le temps consacré à se focaliser sur des concurrents est du temps qui pourrait servir à améliorer le produit ou l’équipe
- Si un concurrent peut forker un projet open source et lancer plus vite, alors cette bataille était probablement perdue d’avance
- En logiciel, la PI et les brevets sont notoirement difficiles à faire appliquer ; réduire l’obsession de protéger des idées logicielles avec des avocats permet d’économiser du temps, de l’argent et de l’énergie mentale
- Une entreprise protège mieux son activité en devenant la meilleure au monde pour mettre en œuvre son idée logicielle
-
La concurrence cloud à un stade plus avancé
- Lorsqu’un projet atteint une certaine ampleur, il peut se retrouver face à de grands fournisseurs cloud qui proposent le produit avec un modèle de distribution plus puissant, comme Elastic ou Mongo
- Le principal problème d’une jeune entreprise reste d’abord d’arriver jusque-là
- Si AWS retire des ressources de l’un de ses produits à plusieurs milliards de dollars pour concurrencer votre offre hébergée, c’est déjà le signe que vous vous en sortez très bien
- Une réponse plus constructive consiste à identifier à l’avance les domaines dans lesquels on peut battre n’importe quel concurrent
- Beaucoup de fournisseurs cloud offrent une expérience développeur (DX) médiocre ; la DX peut donc devenir une compétence centrale
- Si, six ans plus tard, Google tente de vous prendre votre place, votre marque, votre équipe et votre communauté doivent déjà avoir préparé le terrain pour un combat à la David contre Goliath
- Il faut planifier cela dès le départ pour ne pas être pris de court, et utiliser son temps et sa concentration pour bâtir une stratégie gagnante
- Si des concurrents viennent chercher des idées, ils ont toujours un temps de retard, et surtout au début, quand les ressources manquent, s’inquiéter de la concurrence consomme encore plus d’énergie
L’effet sur le recrutement des développeurs
- L’une des grandes difficultés que rencontrent les startups, quelle que soit leur taille, est le recrutement de développeurs
- Il est difficile de sourcer
- Il est difficile d’évaluer les développeurs
- Il est difficile de convaincre de futurs collègues de votre niveau
- L’open source peut aider à réduire ces difficultés de recrutement
-
Sourcing public
- Tous les développeurs bénéficient de l’open source, et beaucoup veulent rendre la pareille en contribuant à des projets open source intéressants
- Les raisons de contribuer peuvent être une bonne communauté, l’apprentissage de nouvelles technologies, ou le plaisir de résoudre des problèmes techniques difficiles dans une base de code inconnue
- Si l’on abaisse la barrière d’entrée aux contributions dans un projet open source, de très bons développeurs peuvent naturellement le découvrir
- Les contributeurs peuvent participer aux discussions d’issues, corriger des bugs, identifier des problèmes et relire des PR
- Tous les contributeurs ne sont pas en recherche d’emploi, mais beaucoup peuvent être attirés par la perspective de travailler à plein temps sur du code open source
- Supabase n’a commencé le recrutement outbound qu’après plus de deux ans d’activité et après avoir embauché 32 développeurs
- L’open source a été l’un des principaux canaux de découverte de talents pour Supabase, et le restera
- Dans une entreprise remote et asynchrone, une stratégie de recrutement open source permet aux candidats de démontrer eux-mêmes leurs compétences, ce qui facilite leur validation
-
De vraies contributions à la place de LeetCode et des tests à faire chez soi
- L’un des éléments que les développeurs apprécient le moins lorsqu’ils cherchent un nouveau poste est de devoir résoudre des problèmes LeetCode ou passer des tests à faire chez soi pendant le processus d’entretien
- Ces méthodes prennent beaucoup de temps, sont pénibles, et représentent souvent mal le travail réel
- Quand quelqu’un contribue à un dépôt, cela fournit déjà les éléments suivants
- Des exemples de la manière dont cette personne communique avec l’équipe et la communauté dans un environnement remote et asynchrone
- Des exemples de contributions de code réelles
- Le candidat peut aussi évaluer l’entreprise
- Il peut voir si l’équipe accorde de l’importance à la qualité du code
- Il peut constater si elle communique efficacement
- Il peut juger si elle prend de bonnes décisions techniques
- Les personnes recrutées via les dépôts Supabase sont devenues indispensables d’elles-mêmes ; certaines ont pris la tête du développement sur des dépôts existants ou lancé de nouvelles bibliothèques clientes et SDK
- Elles n’ont pas eu besoin de résoudre des problèmes LeetCode sur Zoom
Étendre les fonctionnalités de niche et les intégrations
- Lorsqu’on crée une startup, on n’a souvent le temps de résoudre que les plus gros problèmes
- Pour avancer vite, il faut se concentrer sur ce que demande 80 % de la base d’utilisateurs {p:80}
- Les fonctionnalités demandées par une minorité d’utilisateurs sont facilement repoussées indéfiniment
- Si le système est open source, ces utilisateurs peuvent contribuer eux-mêmes à ces fonctionnalités, ce qui augmente l’utilité du logiciel
- Cet effet se voit souvent dans les intégrations et les adaptateurs
- Un utilisateur peut vouloir une intégration Azure ou Vercel
- Si quelqu’un d’autre fournit les ressources de développement pour créer cette connexion, tous les utilisateurs du projet en bénéficient
Ne pas réinventer sans cesse la roue
- Dans un monde sans open source, les entreprises technologiques seraient condamnées à réinventer la roue encore et encore
- Supabase ne se contente pas de publier ses nouveaux projets en open source ; l’entreprise essaie aussi de soutenir des projets open source existants avant d’en créer de nouveaux
- Une situation où des constructeurs automobiles utiliseraient des fonctions propriétaires, des éléments d’interface propriétaires, des bibliothèques de fenêtrage propriétaires, des systèmes d’exploitation propriétaires et des pilotes propriétaires pour afficher des messages d’erreur que l’on verrait à peine représente un gaspillage du temps et des efforts des développeurs
- La Launch Week de Supabase est l’aboutissement du travail de l’équipe et de la communauté sur les 3 derniers mois, et l’un des avantages d’exploiter une entreprise open source se voit dans la vitesse de progression de la communauté
- Pour plus de détails, voir le post Launch Week 4, et pour participer, rendez-vous sur le GitHub de Supabase
1 commentaires
Avis de Hacker News
Il y a ici une grosse hypothèse implicite sur la rentabilité durable, et elle ne correspond pas toujours à la réalité ressentie, surtout si l’on tient compte de choses comme les salaires des développeurs aux États-Unis.
En résumé, une entreprise open source doit être frappée deux fois par la foudre : une fois sur le projet open source, et une autre fois sur l’entreprise.
L’équipe Graphistry aime et pratique l’open source au quotidien ; elle a contribué aux débuts du projet qui a mené à Apache Arrow et Nvidia RAPIDS, et a aussi publié en open source des clients Python/JS. PyGraphistry[AI] est une sorte de couteau suisse pour les graphes, et inclut aussi des outils comme GFQL, qui implémente un langage de requête de graphes de type Cypher sous une forme intégrable, native pour les dataframes et même accélérée par GPU.
Mais la croissance durable vient surtout de la vente, à des entreprises, administrations et sociétés de données, de licences cloud/on-premises auto-hébergées pour notre serveur de visualisation de graphes GPU. Après avoir tenu plusieurs années, cette activité se développe heureusement bien ; le chiffre d’affaires de l’hébergement SaaS suffit à faire vivre une petite équipe, mais pas la majeure partie de l’équipe. Sans les revenus des licences auto-hébergées, la majeure partie du cycle d’innovation disparaîtrait.
J’ai l’impression que cet article passe à côté de l’intersection entre la chance façon gain au loto, les caractéristiques du marché SaaS et la défendabilité technique. Le lancement de Louie.AI et de GFQL change, dans notre cas, les possibilités commerciales de l’open source, donc je ne dis pas que c’est impossible ; mais au vu de l’expérience acquise pour en arriver là, je m’inquiète pour les nouveaux fondateurs qui lisent cet article.
[1] https://graphviz.org/
Autrement dit, la question clé est de savoir si, en leur disant « nous publions maintenant le code source », ces clients répondraient « parfait, alors nous résilions le contrat ».
Il est dit : « Quand je parle de modèles économiques open source avec d’autres fondateurs, trois inquiétudes reviennent sans cesse : on peut se faire critiquer pour du code sale, mauvais ou inachevé ; des hackers peuvent trouver et exploiter des failles de sécurité ; des concurrents peuvent voler la propriété intellectuelle. » À mon avis, il en manque une quatrième.
Amazon/AWS peut commercialiser et vendre un service basé sur mon code sans rien me verser.
Quand j’échange avec des utilisateurs et que je reçois des retours, je reste poli, mais intérieurement je pense : « Facile à dire. Moi, je l’ai vraiment construit. Tais-toi ou envoie une PR. » Sans surprise, ces gens n’envoient presque jamais de PR.
Il faut continuer à faire réellement les choses, et laisser glisser les critiques.
[0] - https://heywillow.io/
Si de grandes entreprises essaient de vous copier, c’est que vous êtes déjà en train de gagner, et il faut prévoir à l’avance comment atténuer ce risque. Mais si j’ai bien compris l’article, ce n’est pas un sujet sur lequel il faut se concentrer ou s’inquiéter au tout début.
Si des entreprises cloud avalent d’autres produits open source, c’est parce que ces produits n’ont pas choisi de licence protégeant correctement leur travail.
C’est un très bon article, vraiment approfondi, mais il y a un point que beaucoup de projets ratent : vendre au secteur public civil.
Le gouvernement américain dispose de nombreux programmes technologiques, comme les subventions de la NSF, et les agences civiles, les agences de renseignement et les États fédérés sont fragmentés entre eux, ce qui finit par créer un paysage d’achat logiciel extrêmement vaste. Les barrières d’entrée liées à la réglementation et à la conformité ne sont pas aussi élevées qu’on l’imagine, surtout si l’on décroche les premiers contrats avec des partenaires. Ce sont généralement des revenus stables et garantis, avec des engagements de 3 à 5 ans capables de financer un projet, et la rentabilité est excellente.
J’aimerais que davantage d’entreprises open source en tirent parti, car des entreprises entièrement privées intègrent souvent des bibliothèques open source dans leurs produits, les revendent avec des marges énormes et gardent tout pour elles.
Exemple : https://x.com/ssankar/status/1749202248700420587?s=20
Quand j’étais dans l’administration, j’ai vu beaucoup de logiciels à 12 millions de dollars qui étaient en fait une combinaison de cartes open source et de bases de données open source. Dans d’autres catégories, j’ai aussi vu de l’OCR PDF facturé 2 millions de dollars par an, ou des outils de type weights & biases à 30 millions de dollars par an.
Il existe aussi des incitations au-delà du déploiement logiciel. Par exemple, corriger en priorité certains bugs ou failles de sécurité. Les agences de renseignement ont probablement payé très cher pour safetensors.
Supabase aurait quatre pistes possibles : vente directe à Cybercom, vente directe au DOS ou contrat d’équipe, vente au VA via un PWS, ou vente directe à de grands fournisseurs de logiciels sous contrat public.
Pour s’y prendre, on peut envoyer des cold emails à des GS 14/15 ou équivalents, embaucher un ancien GS15, ou chercher les appels d’offres pertinents sur SAM.gov puis préparer une proposition, soit avec GovPro.ai en service complet, soit en mode autonome avec rogue.
Le temps que la bureaucratie publique donne son approbation finale au contrat, la plupart des startups ont probablement déjà épuisé leur trésorerie.
Les contrats peuvent être rentables, mais la bureaucratie est énorme et il faut quelqu’un qui ait de l’expérience pour la gérer. Ce n’est pas une voie adaptée à tout le monde, et cela demande beaucoup de temps et de négociation.
Au-delà même de l’immense bureaucratie, le gouvernement fédéral est l’organisation publique la plus grande, la plus lente et la plus difficile à gérer. Rien qu’aux États-Unis, il existe des dizaines de milliers d’autres entités publiques : écoles, villes, comtés, États, districts des eaux, services d’incendie, bibliothèques, etc.
Si vous voulez entrer dans le secteur public, mieux vaut viser petit et large plutôt que de tout miser sur le plus gros acteur.
Le secteur public le plus rentable au monde est le département de la Défense des États-Unis.
Mais le département de la Défense est incroyablement bureaucratique, très sensible aux calendriers, et obsédé par le secret.
Le modèle économique de Supabase consiste à se présenter comme une entreprise open source, mais en pratique, aucune personne sensée ne voudrait l’héberger elle-même pour de la production
À cause de choses comme une documentation subtilement incomplète, des bugs subtils, ou des fonctionnalités importantes subtilement absentes. Ils obtiennent donc les éloges liés à l’open source, mais en réalité ce n’est pas vraiment exploitable, et j’y vois simplement un outil marketing
Le premier, c’est la tranquillité d’esprit. Même si on ne l’héberge pas soi-même aujourd’hui, on dispose d’une voie de sortie supplémentaire si le service ne convient plus. Bien sûr, il faut aussi fournir un accès aux données brutes
Le deuxième, c’est la qualité du code. Si vous avez déjà eu affaire à du code vraiment mauvais qui, en apparence, fonctionne bien, vous savez à quel point il est important d’avoir du code qu’on n’a pas honte de publier
Le troisième, c’est la possibilité de contribuer. Avant, je n’y voyais pas grand-chose, mais après l’avoir vécu plusieurs fois, pouvoir demander ou apporter soi-même une contribution lorsqu’il manque une fonctionnalité, qu’il y a un bug ou un problème de performance, c’est énorme. Dans la plupart des projets à source fermée, on a déjà de la chance s’il existe seulement un canal transparent pour demander des fonctionnalités
Au-delà d’un certain seuil, des gens peuvent décider de consacrer des efforts à un fork. MariaDB en est un exemple
Certaines personnes nous ont même dit directement que c’était précisément ce point qui les rassurait dans le fait d’utiliser le service managé de notre entreprise
Il semble bien plus simple de devenir une vraie entreprise open source, légitime
Si ce n’est pas ce que cela voulait dire et que j’ai mal lu, alors le reste du texte donne au contraire une image très positive de Supabase
Ce n’est peut-être pas viable commercialement, mais l’état actuel érode fortement les standards que l’on peut attendre d’un logiciel open source, et je ne vois pas non plus de bénéfice clair à long terme pour les entreprises qui choisissent cette approche
Même si un développeur ne l’exécute pas lui-même, cela lui permet de voir le code qui tourne réellement
J’aime Supabase, j’aime aussi l’open source commercial en général, et je suis d’accord avec une grande partie de l’article
Mais le passage « dans le logiciel, les idées ne valent pas grand-chose. La valeur vient presque toujours de l’exécution de ces idées » me paraît étrange
J’ai déjà entendu cette formule dans des situations du type : « J’ai une super idée de startup, tu peux signer un NDA avant que je t’en parle ? »
Mais si l’on publie un logiciel en open source, on ne fournit pas simplement une idée : on fournit aussi une part importante de l’exécution de cette idée
Bien sûr, le code n’est pas toute l’exécution ; cela s’étend aux ventes, au marketing, au support, etc. Malgré tout, j’ai l’impression que l’article sous-estime beaucoup la valeur du code et suggère qu’il ne vaut rien sans ventes, marketing, etc., ce qui me semble faux
Si je devais répartir la valeur, je dirais 90 % ventes/marketing/validation client, 10 % code. Je gère un SaaS bootstrappé dont le chiffre d’affaires est dans le bas des sept chiffres, et je peux dire que le code est globalement en désordre et évolue en permanence
On ne peut pas copier gratuitement une maison, mais on peut le faire avec un logiciel
Ce pour quoi les développeurs sont payés, c’est le processus de création du code et la résolution de tous les petits problèmes invisibles
C’est pour cela que la vente de logiciels est aussi rentable. Si l’on ne vend pas le logiciel, on ne peut pas gagner d’argent avec lui. Le logiciel n’est pas comparable aux objets physiques de la réalité que nous partageons
Pour moi, la question centrale n’est pas de savoir si le code est assez bon, ni si les concurrents vont le copier, mais s’il est possible de gagner assez d’argent pour bâtir une activité durable
Les projets open source cités et appréciés ne sont pas de bonnes entreprises : PostgreSQL, Python, Bitcoin, React
Mongo et Elastic sont excellents, mais ce sont des exceptions. Il existe davantage d’entreprises de bases de données à source fermée qui ont réussi que d’entreprises de bases de données open source
Une entreprise open source, c’est difficile. Mais pour les utilisateurs, c’est très précieux
Si l’on met de côté le débat sur ce qu’est une licence « open source », l’important est que ces entreprises ont estimé que les licences largement utilisées comme (A)GPL, Apache ou MIT laissaient beaucoup de place aux concurrents pour créer des services managés/hébergés et rivaliser par l’échelle. Par exemple, Amazon a proposé OpenSearch comme une version moins chère d’ElasticSearch
[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...
Il me semble que cette question signifie : « Notre entreprise doit-elle publier le code source de son logiciel ? »
Mais pour moi, répondre à la question originale fournit une piste pour répondre à cette question reformulée. La question originale ne porte pas sur le logiciel que l’entreprise vend, mais sur la nature du logiciel qu’elle utilise
Personnellement, s’il existe une alternative, je choisirai toujours un produit open source. Même si je dois payer le support ou faire un don au projet. L’accès libre au code source est fondamentalement important, même pour un logiciel que je n’ai absolument pas l’intention de modifier
Je sais que cela paraît extrême à beaucoup de gens. Mais je déteste l’idée de ne pas pouvoir démonter un micro-ondes, une poignée de porte ou une boîte de vitesses. Je ne serai peut-être pas capable de les remonter correctement, mais je pourrais trouver un engrenage édenté et faire une réparation à 2 dollars au lieu d’un remplacement à 90 dollars. Ou bien fabriquer un micro-ondes Frankenstein avec une boîte de vitesses
Étendre les fonctionnalités d’un serveur web ou comprendre pourquoi mon plugin fait planter l’application hôte est important pour moi. Je pense que c’est aussi important pour la société. C’est pour cela que je reste attaché à mon extrémisme open source. Si l’on me montre un serveur web ultracompact dernier cri qui gère HTTPS/4 en moins de 5 Ko grâce à une IA intégrée, cela m’intéressera, mais s’il n’est pas open source, je continuerai à utiliser ma stack actuelle
C’est cet état d’esprit qui fait que les logiciels que je crée sont open source, et parfois les gens paient pour cela
À propos du passage disant que « si, dans six ans, Google essaie de vous voler votre déjeuner, il vous faut une marque, une équipe et une communauté qui se préparent depuis des années à un combat David contre Goliath », d’après mon expérience, pour les responsables des achats, des choses comme la marque, la communauté, l’équipe ou l’expérience développeur comptent très peu par rapport à la conformité
C’est particulièrement vrai si l’on affronte frontalement un fournisseur établi comme Google
Dans le cas de Supabase, c’est tout à fait juste, car nous avons effectivement travaillé ces dernières années sur des conformités comme SOC2, HIPAA et le RGPD pour répondre à ce type d’exigences
Notre produit aussi réfléchit à ce problème. Un jour, nous passerons tout en open source sous licence MIT ou Apache, selon celle qui nous conviendra le mieux à ce moment-là, et nous l’avons aussi indiqué publiquement sur le site. Ce ne sera pas du type AGPL ni open core
Mais j’ai eu le sentiment qu’il était totalement impossible de gagner de l’argent avec le produit dans une telle structure, et mes expériences précédentes allaient dans le même sens. Le consulting est possible, mais un produit, c’est autre chose. Supabase a levé énormément de capital-risque, et c’est le cas de presque tous les « grands » projets open source
Si vous êtes autofinancé, surtout sur un projet ambitieux et difficile, vous ne pourrez pas facturer pendant un bon moment. Les gens ne peuvent travailler gratuitement que pendant une durée limitée, et une petite équipe qui reste en communication étroite autour d’un code privé peut avancer beaucoup plus vite en réduisant l’overhead nécessaire à un projet open source réussi
J’aimerais entendre des exemples de projets d’une taille comparable, avec 0 dollar de financement, lancés au cours des cinq dernières années, avec au moins deux personnes à temps plein, qui durent depuis plus de trois ans et recommandent encore cette approche. Je suis curieux de savoir comment ils gagnent leur vie. Je pense que des histoires comme Redis ne se produisent plus aujourd’hui. En tout cas, je n’en ai pas vu. Même un projet simple comme langchain a reçu des dizaines de millions de dollars de capital-risque, alors que je pensais justement que ce genre de projet aurait pu être un bon candidat pour une petite équipe gagnant de l’argent via plusieurs sources de revenus
Tous mes logiciels sont publiés dans le domaine public, c’est-à-dire comme logiciels libres, mais aucun n’est devenu un projet open source ou une communauté à succès. Le logiciel libre est d’abord et avant tout une idéologie, puis seulement une pratique ou une fonctionnalité
Je pense que passer une entreprise en open source n’a pas de sens, sauf si l’on s’adresse aux développeurs ou si l’on construit un produit que, dans les faits, personne ne va héberger soi-même
Supabase est l’exemple type de ces deux cas. Comme exemple du second, il y a Plausible Analytics, qu’on peut effectivement auto-héberger. C’est ce que je fais avec Coolify.io. Mais si vous ne créez pas votre propre système CI/CD pour récupérer et fusionner les mises à jour depuis les releases, vous finirez par les manquer