L’open source ne gagne pas parce qu’il est moins cher
(github.com/getlago)- Les entreprises d’open source commercial ont du mal à durer en ne proposant qu’un substitut à des produits payants existants affublé d’une licence MIT ; il faut une vraie raison d’être open source ou un produit supérieur
- Contrairement aux projets à but non lucratif ou financés par des soutiens, un business open source a besoin de revenus pour recruter, croître et poursuivre le développement
- Les jeunes entreprises choisissent facilement une offre gratuite ou une version open source, tandis que les grands groupes traitent les coûts SaaS comme une ligne budgétaire ; il est donc difficile de renverser une décision d’achat par le seul argument du prix bas
- L’open source devient particulièrement fort lorsqu’un code source fermé crée un problème de transparence qui érode la confiance des clients, et lorsqu’il existe un problème d’extensibilité nécessitant de nombreuses intégrations et plugins
- Les cas de PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte et Elastic montrent que l’open source peut devenir un meilleur produit grâce à l’auditabilité, à l’auto-hébergement et aux contributions de la communauté
Un simple substitut open source ne suffit pas
- Des descriptions comme « la version open source de Stripe Billing » ou « la version open source de Chargebee » sont utiles pour faire comprendre rapidement le produit, mais restent faibles comme justification pour bâtir une activité durable
- Un outil d’open source commercial peut difficilement se reposer uniquement sur son positionnement d’alternative open source à un produit payant déjà établi
- Il ne suffit pas qu’un développeur imite un produit et y appose une licence MIT, et l’open source en soi ne garantit pas non plus le succès
- Le sujet ici concerne les projets d’open source commercial qui rivalisent avec des solutions payantes populaires
- Les produits centrés sur la communauté ou financés par des soutiens, comme React, TypeORM ou VSCode, obéissent à d’autres priorités
- React bénéficie du soutien d’une organisation plus grande comme Meta, et TypeORM finance son développement par les dons
- Ces projets ne sont pas fondamentalement des entreprises
- Pour réussir, une entreprise open source doit avoir une raison claire d’être open source, ou être meilleure que ses concurrents
Le critère de réussite n’est pas l’usage mais le revenu
- Hormis les projets non lucratifs financés par des dons ou par une maison mère, le critère final d’un business open source classique est le revenu
- Une entreprise à but lucratif finance grâce à ses revenus le recrutement, la croissance, la pérennité et la poursuite du développement
- Une entreprise qui crée du logiciel gratuit tout en générant des revenus est un cas positif ; une société open source ne cherche pas à exploiter excessivement ses clients, mais à continuer d’exister
- MongoDB est devenu un grand éditeur de bases de données avec plus de 4 600 employés
- L’entreprise est ensuite passée à la licence SSPL afin de limiter le déploiement du service par des cloud providers qui contribuaient peu ou pas au projet
- La SSPL n’a pas été approuvée par l’OSI, mais elle est présentée comme très proche de l’open source en pratique
- Lorsqu’on mesure le succès à long terme, il faut distinguer adoption et chiffre d’affaires
- Un projet peut être très adopté et pourtant disparaître s’il ne génère pas de revenus
- L’idée que la communauté reprendra naturellement le projet est jugée peu étayée par des preuves
Le faible prix n’est pas un avantage durable
- Une stratégie qui vise uniquement des clients sensibles au prix ressemble de près à une bataille perdue
- Dans l’exemple hypothétique d’une version open source d’Amplitude, on peut soutenir qu’Amplitude est cher, qu’il pèse sur les jeunes entreprises et que même les grandes sociétés pourraient économiser de l’argent
- Mais les jeunes entreprises, justement parce qu’elles sont sensibles au prix, ont de fortes chances de choisir une version open source ou une offre gratuite, ce qui ne suffit généralement pas à soutenir l’activité
- La stratégie consistant à créer une alternative moins chère ressemble souvent davantage à un billet pour une faillite future
- Les grandes entreprises, elles non plus, ne craignent généralement pas de faire faillite à cause de la facture d’Amplitude
- Lors des négociations contractuelles, elles peuvent bien sûr discuter le prix dans le cadre du budget
- Mais la plupart des SaaS ne restent au final qu’une ligne parmi les dépenses
- Les critères plus importants sont la qualité de la solution, sa pérennité et sa facilité d’exploitation
- Déployer une solution open source peut être difficile à administrer
- L’exception survient lorsque le coût de la solution représente une part très importante du budget total
- C’est le cas d’entreprises qui ont dû réduire Oracle après une envolée des coûts liée à l’usage de la base de données
- Mais la plupart des solutions open source ne remplacent pas l’un des trois principaux postes de dépense, ce qui rend difficile de faire du prix le premier critère de décision
Première manière de gagner pour l’open source : la transparence
- Le cas typique où une solution open source devient très forte est celui où un code fermé crée un problème de transparence qui installe de la défiance entre client et fournisseur
- Parmi les alternatives open source à Amplitude, on trouve PostHog
- PostHog s’est développé avec des clients comme Airbus, DHL et Staples
- Le produit combine plusieurs solutions SaaS orientées produit et est proposé en open source
- Même le code source du blog et la roadmap sont publics
- PostHog s’est imposé comme un meilleur produit que ses concurrents notamment parce que les outils d’analytics traitent des données client sensibles comme les adresses IP, les noms ou les enregistrements de session
- Dans un contexte où se multiplient les réglementations sur les données comme le RGPD ou le CCPA, il peut être problématique de confier le stockage de telles données à un tiers
- PostHog offre deux options
- Auto-héberger soi-même la solution d’analytics
- Mandater PostHog comme tiers tout en conservant de la transparence sur la manière dont les données sont stockées et sur la façon de migrer plus tard vers un auto-hébergement
- Même si l’auto-hébergement est l’approche la plus respectueuse de la vie privée, beaucoup d’entreprises peuvent tout de même choisir le modèle hébergé
- Dans ce cas aussi, elles peuvent voir ligne par ligne comment le logiciel fonctionne
- Elles peuvent savoir comment passer au modèle auto-hébergé lorsqu’elles en ont besoin
- Une entreprise open source ne gagne pas en supprimant le besoin d’un tiers, mais en gagnant la confiance grâce à la possibilité d’auditer publiquement son fonctionnement
Exemples de produits où la transparence est importante
- Medplum est une plateforme de dossier médical électronique open source qui concurrence des acteurs historiques fermés
- Parce qu’elle est open source, les utilisateurs peuvent vérifier précisément ce que la plateforme prend en charge ou non
- SuperTokens est une alternative open source à des solutions d’authentification comme Auth0
- La connexion traite des données sensibles comme le nom, l’e-mail et le mot de passe
- Le caractère open source aide à instaurer davantage de confiance
- TableFlow est une alternative open source à des plateformes d’import CSV comme Flatfile
- Le point important est que les données importées peuvent être sensibles
- Minio est une alternative open source au stockage AWS S3
- S3 peut contenir des PII clients, via des captures d’écran ou des fichiers JSON structurés
- Minio peut être une alternative pour les entreprises soucieuses de savoir qui peut accéder aux données utilisateurs
- AWS affirme que ses employés n’accèdent pas directement aux données clients, mais avec un code fermé, cette affirmation reste une question de confiance
- Lago traite lui aussi des informations de facturation et d’usage produit ; ces informations s’apparentent à du contenu sensible, et l’open source peut donc mieux renforcer la confiance des utilisateurs
Deuxième manière de gagner pour l’open source : l’extensibilité
- L’un des grands avantages de l’open source est d’ouvrir à la communauté le développement de fonctionnalités de niche
- Le produit cœur est en général maintenu par une équipe d’ingénierie centrale, tandis que les intégrations ou plugins sont créés par des développeurs de la communauté, puis parfois fusionnés dans la branche principale
- Une solution fermée, dépendante de sa seule équipe d’ingénierie interne, s’étend plus difficilement de cette manière
- Cet avantage est particulièrement fort pour les entreprises open source qui créent des systèmes devant se connecter à de nombreuses bibliothèques, frameworks et applications
- Airbyte est une plateforme ELT open source qui a beaucoup grandi grâce aux connecteurs ajoutés par la communauté
- Elastic, autre entreprise plus grande issue de l’open source, propose elle aussi de nombreuses intégrations de données
- SuperTokens a fait de l’extensibilité une proposition de valeur centrale, et le fait que des membres de la communauté puissent créer des intégrations avec des fournisseurs d’authentification rares profite à tout le monde
Troisième manière de gagner pour l’open source : un meilleur produit
- La transparence et l’extensibilité contribuent à faire de l’open source commercial un meilleur produit sur le long terme
- Les projets open source peuvent tirer parti des retours et de l’aide de la communauté pour évoluer plus vite que des solutions fermées
- PostHog a commencé comme une alternative à Amplitude et FullStory, puis est devenu une solution large et complète qui concurrence aussi LaunchDarkly et Pendo
- PostHog a levé 15 millions de dollars en Series B
- Cette croissance s’est produite au cours des dernières années, et PostHog considère sa communauté comme l’une des raisons clés
- Les projets open source ne se limitent pas à l’open source commercial et jouent depuis des décennies un rôle moteur dans l’amélioration des produits
- Certains logiciels peuvent rester fermés en raison de la nature de leurs effets de réseau
- Mais dans les domaines où la transparence et l’extensibilité sont des enjeux, un nouvel entrant open source peut constituer une menace réelle
3 commentaires
Je suis tombé dessus par hasard en faisant une recherche, et je me demande quand l’IA corrigera enfin ce genre de traduction littérale de l’anglais (« par le fait d’être bon marché »).
Voici le résultat de l’exécution de Claude 4.5 Sonnet aujourd’hui (2026-01-12)
« L’open source ne gagne pas parce qu’il est moins cher »
Prompt
L’open source ne gagne pas simplement parce que son prix est bas.
Les facteurs de succès de l’open source ne résident pas dans son faible coût, mais ailleurs.
Si l’open source prend l’avantage, ce n’est pas en raison de son prix bas.
Avis sur Hacker News
Le terme profit employé ici est étrange et ambigu.
J’ai géré des projets open source et de logiciel libre pendant près de 24 ans, et environ 17 de ces années ont aussi généré du chiffre d’affaires, mais il n’y a jamais eu de « profit », seulement du chiffre d’affaires (revenue).
Au sens où l’entendraient généralement une entreprise ou un comptable, le profit est l’argent qui reste après avoir déduit la rémunération des personnes impliquées dans le projet et les coûts.
Les seuls projets open source qui ont besoin d’un profit dans ce sens sont ceux qui ont reçu un investissement en capital de la part d’investisseurs attendant un « rendement » ; il en existe, mais ce n’est pas la majorité.
Et, comme souvent dans les articles qui arrivent sur HN, l’ensemble est beaucoup trop centré sur le web/SaaS. Aussi difficile que cela puisse paraître à croire, il existe d’autres types de projets open source.
Dans ce contexte, ce qui reste après avoir encaissé du chiffre d’affaires et payé les coûts est le profit, et ces coûts incluent des choses comme les salaires fixes, les contrats de travail et les fiches de paie.
Une entreprise peut utiliser son profit de multiples façons. Elle peut le constituer en réserve de trésorerie pour pouvoir payer les coûts lors des mois où le chiffre d’affaires est faible, acheter des actifs comme du nouveau matériel, ou permettre de recruter davantage. Même si c’est moins courant qu’on pourrait le penser, elle peut aussi le verser aux propriétaires sous forme de dividendes.
Pour votre situation, faute de nombreux détails, on ne peut que supposer, mais si vous travaillez seul et que le projet est petit au point de ne pas nécessiter ni souhaiter d’embauche, le chiffre d’affaires ressemble en réalité à un revenu personnel. Certains mois vous touchez plus, d’autres moins ; dans ce contexte, il est juste de parler de chiffre d’affaires plutôt que de « profit ».
C’est d’autant plus vrai s’il s’agit de logiciel avec très peu d’autres frais généraux, où le suivi des dépenses à des fins fiscales n’a pas grand intérêt, et où vous ne tenez peut-être même pas vraiment de comptabilité. Dans ce cas, je comprends pourquoi l’article ne vous parle pas. Il traite d’une situation assez différente.
Si des investisseurs purement financiers n’exigent pas de rendement continu, la pression diminue fortement, et il devient plus facile de faire ce qui convient au projet.
Mais dans des catégories de produits où l’on est en concurrence avec des entreprises ambitieuses, la croissance est aussi nécessaire, et probablement rationnelle.
Conserver du profit en prévision des récessions, des opportunités ou de grosses dépenses n’est pas seulement raisonnable. Plus il y a de participants et de clients, plus les raisons de ne pas brûler tout le chiffre d’affaires entrant deviennent importantes.
Dans les grandes entreprises, ces deux chiffres sont souvent sans rapport l’un avec l’autre, et chacun est défini selon la personne à qui il est communiqué et les règles applicables à cette communication.
Il peut aussi exister quelque chose comme un « profit de gestion », terme générique pour des indicateurs non standardisés et non réglementés. Par exemple, même si une entreprise s’est écartée de la comptabilité de caisse à des fins fiscales et de reporting aux investisseurs, il peut rester utile pour les dirigeants historiques de continuer à suivre l’ancienne définition du profit. Cela peut être par habitude, parce qu’elle reflète bien les flux de trésorerie, ou parce qu’elle est utile autrement.
C’est l’un de ces problèmes un peu postmodernes. La SEC, l’IRS ou le chargé de compte bancaire n’acceptent pas des expressions comme « profit SEC » et demandent le « vrai » profit. Un peu comme un élu local naïf qui demanderait à un hôpital combien cela a « vraiment » coûté à l’entrepreneur.
Quoi qu’il en soit, l’auteur emploie lui aussi les termes selon son propre point de vue, comme la SEC ou l’IRS. Quand il dit que « l’open source ne gagne pas parce qu’il est moins cher », l’« open source » désigne les entreprises open source sur le modèle de MongoDB. Les investisseurs et les objectifs de croissance sont donc implicites.
L’article l’a d’ailleurs clarifié lui-même, il n’y a donc pas vraiment lieu de se lancer dans des grognements sémantiques.
Le problème de ce modèle économique, c’est qu’il crée une tension entre la version OSS et la version payante.
On veut que la version OSS soit bonne, mais pas au point que plus personne ne ressente le besoin de payer pour du SaaS, du conseil, etc.
Cette tension semble finir par mener soit à l’absence de fonctionnalités manifestement nécessaires, soit au fait que des fonctionnalités ou des connaissances indispensables pour l’exploiter à grande échelle soient cachées en source fermée afin de monétiser l’entreprise qui finance le projet.
Quand le produit relève de l’infrastructure, le schéma consistant à passer à une licence qui permet seulement de regarder, sans toucher pour empêcher les grands fournisseurs cloud de l’engloutir sous forme de service en un clic, comme Elastic ou Hashicorp, est déjà bien installé.
Je ne dis pas que l’article a tort, mais j’aimerais qu’on arrête de faire comme si l’OSS soutenu commercialement était un win-win kumbaya bénéfique pour tout le monde. En réalité, cela ressemble davantage à un growth hack utilisé par une startup pour gagner en crédibilité, puis, quand vient le moment de générer du chiffre d’affaires, à une structure qui finit d’une manière ou d’une autre par serrer la communauté qui l’a aidée à croître.
En maintenant un petit module, j’ai reçu pendant des années beaucoup de demandes de fonctionnalités et de support. Tant que je n’ai pas gagné de quoi payer mon loyer, je ne ressens pas la moindre culpabilité à faire payer ce travail.
Même le fait d’appuyer sur le bouton de fusion d’une Pull Request : si cela me prend ne serait-ce qu’une seconde, je facture. J’ai passé des mois, des années sur le code, et je l’ai rendu gratuitement disponible au monde entier.
Si vous voulez des fonctionnalités supplémentaires ou mon temps, il faut payer.
Le fait que beaucoup d’entreprises échouent ne signifie pas que ce modèle économique ne fonctionne pas ; cela signifie plutôt qu’il est très difficile de bien le faire.
Cela dit, si l’on part du principe que la plupart des gens sont globalement bien intentionnés, il vaut la peine d’envisager que ces entreprises ou ces personnes se soient simplement trompées dans leur approche du marché. Cela peut relever de l’incompétence plutôt que de la malveillance.
Si, dès le premier jour, elles indiquaient clairement et en toute transparence ce qui restera gratuit pour toujours et ce qui deviendra finalement payant, je ne considérerais pas cela comme une trahison de la communauté.
À condition, bien sûr, de respecter la feuille de route et de l’ajuster en fonction des retours et des contributions.
Le support payant ou les fonctionnalités avancées peuvent rester dans le domaine commercial, là où le logiciel rapporte de toute façon l’essentiel de l’argent.
Cela ne conviendra pas à tous les cas d’usage, mais ce n’est pas nécessaire. La majeure partie de l’informatique devrait être personnelle.
Il est dit que « MinIO est une bonne alternative pour les entreprises qui se soucient de savoir qui accède aux données des utilisateurs », mais une entreprise ne pourrait-elle pas prétendre héberger avec un logiciel open source tout en utilisant en réalité un logiciel interne propriétaire qui imite les mêmes points de terminaison d’API ?
Dans ce cas, il faut toujours le même type de confiance qu’avec AWS.
Il ne faut pas supposer que l’auto-hébergement est synonyme de forte culture de sécurité. Dans la plupart des entreprises, l’IT on-premise est traité comme le CVC ou l’installation électrique, simplement en plus pénible.
N’importe qui en bleu de travail pourrait embobiner l’accueil pour obtenir la clé de la salle serveurs.
Cela veut seulement dire que le fournisseur partage le code source qu’il affirme faire tourner derrière son service.
Même si ce code est exactement le bon, il est peu probable que ce soit le seul code qui tourne derrière le service « officiel ». Et l’utilisateur ne peut pas non plus le compiler lui-même pour le déployer sur leurs serveurs.
L’open source n’a un vrai sens que lorsqu’on auto-héberge ; sinon, ce n’est en pratique pas différent d’un logiciel propriétaire. Tout repose sur la confiance envers le fournisseur, et si possible sur le contrat.
Par exemple, si le contrat stipule que les données entrent et sortent via ce code open source sans aller ailleurs, et énumère des procédures destinées à le garantir, mais que l’ensemble est un mensonge flagrant, cela devient un gros problème de manière claire et exécutoire.
Ce serait aussi difficile à cacher aux employés en interne, et les gens arrivent et repartent. Si ce n’est pas vrai, ils ont peu de chances de faire une telle affirmation.
L’auteur précise qu’il parle spécifiquement de solutions open source en concurrence avec des produits payants.
Personnellement, dans ce contexte, je ne pense pas que la question de savoir si l’open source « gagne » soit encore tranchée.
Ces dix dernières années, les produits open source se sont fortement multipliés, et depuis environ cinq ans, on a aussi vu beaucoup d’entre eux s’éloigner de l’open source. MongoDB, la stack Hashicorp, Elastic, Red Hat, MinIO, etc., en sont des exemples.
Il ne reste pas beaucoup de produits véritablement open source et commercialement compétitifs, et beaucoup d’entre eux essaient encore de prouver que c’est un modèle économique viable.
J’ai fait une présentation sur ce sujet lors d’un événement interne de l’entreprise il y a quelques semaines, et je la referai dans quelques semaines à GoWest.
Le postulat central est qu’une licence open source accorde littéralement des libertés, mais ne fournit pas les autres choses pour lesquelles une entreprise serait prête à payer. Une licence propriétaire fournit ce dont l’entreprise a besoin, mais au prix de ces libertés.
Je crois qu’il existe un troisième modèle, qui fonctionne entre les deux sans compromis sur la liberté ni sur la fiabilité. En restant open source et en comblant, par du sponsoring, l’écart avec ce dont les entreprises ont besoin, cela peut fonctionner pour certains projets.
Nous sommes en train de repenser le site web de Caddy autour de ce message, et j’espère que cela marchera bien.
Est-ce cela que vous voulez dire par « s’éloigner de l’open source » à propos de MinIO ?
Le titre est idiot. Bien sûr que l’open source gagne parce qu’il est moins cher.
Ce que l’auteur veut dire, c’est que le business open source ne gagne pas parce qu’il est moins cher.
Une base de code open source gagne toujours parce qu’elle est moins chère. Personne ne paie pour un algorithme de compression, un démon de temps réseau ou un transcodeur média. L’open source a complètement fait disparaître ces marchés.
Mais c’est agaçant que le titre soit littéralement faux à cause d’un seul mot.
Je suis retourné relire les premiers paragraphes en me demandant si j’avais raté quelque chose.
Du point de vue d’un ingénieur qui influence l’adoption de technologies, l’open source gagne parce qu’il est compréhensible.
Si mes collègues et moi pouvons lire le code source, nous pouvons juger si le produit fera ce qu’il prétend faire.
Si nous rencontrons un bug ou un cas d’usage inattendu en l’utilisant, nous pouvons au moins enquêter sur une solution et la proposer dans un rapport de bug, voire ouvrir une PR.
Cela permet de trouver rapidement un contournement, et généralement aussi de signaler un bug.
Les entreprises ne se soucient pas tant que ça du code lui-même. Et même si c’est le cas, des clauses de continuité d’activité peuvent lever l’essentiel des inquiétudes liées au code fermé.
Au final, combien d’institutions financières sont passées d’Excel à OpenOffice Calc ?
La stratégie de mise sur le marché d’AWS reposait sur l’attraction des startups et des développeurs indépendants grâce à des services peu coûteux, facturés à l’usage, et cela a très bien fonctionné. Airbnb, Stripe, Twitch, etc., sont devenus de grandes entreprises en grandissant avec AWS.
Peu de choses peuvent rivaliser avec le faible coût ou le gratuit. On peut toujours monter en gamme plus tard. Il suffit de demander à ARM et Intel.
Pour les jeunes entreprises d’outils de développement, l’open source est devenu de fait la stratégie d’entrée sur le marché par défaut. Comme l’article le souligne à juste titre, ce n’est toutefois pas un modèle économique.
Donc, à moins d’être aussi excellent que Snowflake et capable d’affronter aussi le camp libre et open source comme Databricks, le modèle open core est préférable.
Elles préfèrent largement pouvoir le compiler elles-mêmes.
Si vous installez vous-même Postgres sur un serveur physique, les investisseurs s’en moqueront, ou bien ils poseront des questions difficiles sur le temps que vous avez gaspillé. Dans ce cas, il faut avoir une très bonne réponse, ou des investisseurs capables de comprendre.
Je suis surpris que le verrouillage fournisseur ne soit pas mentionné. C’est un argument de vente évident de l’open source.
Bien sûr, cela dépend des organisations et des personnes, et beaucoup ne se soucient pas du verrouillage lorsqu’il s’agit d’une entreprise en laquelle ils ont confiance, mais ce n’est jamais nul.
Quand je travaillais chez Red Hat comme consultant OpenShift, j’ai rencontré beaucoup de dirigeants préoccupés par le verrouillage fournisseur. Pour eux, choisir OpenShift allait de soi.
C’est un sujet seulement vaguement lié à la vente de logiciels, mais il y a longtemps, j’ai vendu une mise à jour de l’interface utilisateur pour un jeu dont la conception était médiocre.
J’avais fixé son prix au double de celui du jeu lui-même, et pourtant les gens l’ont achetée. Parce qu’elle était conçue de façon professionnelle.
En tant que designer professionnel, j’avais pris du temps sur mon activité principale pour faire quelque chose que le développeur n’avait probablement pas su faire.
Dans les commentaires de la plateforme de distribution numérique où je la vendais, la plainte la plus nette était que la mise à jour était trop chère, et les gens commentaient évidemment le positionnement tarifaire.
Mais une chose était claire : le jeu lui-même était trop bon marché.
Si les gens se plaignent seulement du prix tout en continuant à acheter, cela signifie qu’ils n’ont rien d’autre à reprocher.
Les oiseaux veulent toujours de la nourriture gratuite. Il ne faut pas se caler sur eux.
À noter aussi que cette mise à jour a été distribuée illégalement et a pas mal circulé chez les utilisateurs de versions piratées. J’en étais plutôt content, puisque la plupart des clients avaient payé.
Il était également clair que je répondais à un ensemble de fonctionnalités désirées qui n’étaient proposées nulle part ailleurs. Ce genre de problème est plutôt bon signe : cela veut dire qu’on a créé quelque chose que les gens veulent.
Beaucoup de projets open source ne le deviennent pas par choix, mais par nécessité
Certains produits n’ont ne serait-ce qu’une chance d’être adoptés que s’ils sont open source
L’auteur se concentre sur une petite élite de projets open source, qui ne représente pas la grande majorité des projets open source
Certaines entreprises disposent des bons contacts dans le monde des affaires ou au sein des administrations, ce qui leur permet de vendre facilement des licences produit à prix élevé, mais elles sont minoritaires
La plupart des gens et des petites entreprises n’ont pas ce réseau. Sans réseau d’affaires adapté, il est difficile de gagner ne serait-ce qu’un peu d’argent
Peu importe la qualité du produit ou les coûts qu’il peut faire économiser à quelqu’un. Personne n’y croit et personne ne l’essaie. Même si les bénéfices à long terme peuvent être considérables, la barrière à l’adoption est trop élevée
Rendre le produit open source est le seul moyen de mettre un pied dans la porte. Cela lui donne une infime chance d’être remarqué, et parfois, c’est tout ce qu’il y a