Comment concurrencer efficacement un projet open source?

Une entreprise avec un projet open source solide en concurrence avec un produit traditionnel à source fermée semble impossible à battre.

J'ai lu cet article dans lequel l'auteur expose ce scénario:

Supposons que l'on puisse diviser un marché de logiciels, par exemple la gestion de réseau, entre deux produits. L'un faisait tout ce qui était possible et coûtait 1 million de dollars, l'autre, 10% de plus, mais était gratuit et ouvert.

Le prix de la solution commerciale filtrerait automatiquement un grand nombre d'utilisateurs, qui devraient alors se tourner vers l'open source. Mais certains utilisateurs seraient satisfaits de la fonctionnalité de 10% et la choisiraient d'emblée.

Par exemple, j'ai un ordinateur Macintosh d'origine sur mon bureau. Il exécute un traitement de texte appelé MacWrite. Il fait tout, à l'exception de la vérification orthographique, pour lequel j'ai besoin d'un traitement de texte. Je peux formater des paragraphes, choisir des polices de caractères, mettre du texte en gras ou en italique et même coller des images et des graphiques. Tous dans une interface utilisateur "ce que vous voyez est ce que vous obtenez".

Il occupe 76K d'espace disque. C'est "K" comme dans "kilo-octet".

Comparez cela à Microsoft Word. Je pense que la dernière fois que j’ai installé Word, c’était environ 30 Mo, beaucoup plus gros que MacWrite, mais je ne l’utilise pas beaucoup plus que MacWrite. Comme moi, de nombreux utilisateurs sont satisfaits des fonctionnalités de base. Ils n'ont pas besoin de toutes les cloches et de sifflets.

Mais revenons à mon analogie. Au début, la société commerciale ignorerait probablement le projet open source. Cela ne représente aucune menace pour leur source de revenus, alors pourquoi devraient-ils prêter attention à un débutant?

Si ce projet est sain et durable, cependant, dans environ un an, il réalisera peut-être 15% à 20% de ce que fait le produit commercial. Cela devrait faire perdre un peu plus d’utilisateurs à leur entreprise et peut-être qu’ils commencent à y faire attention.

Très probablement, cette attention prendrait la forme de marketing contre le projet. Ils prétendent qu'il est trop petit ou trop insuffisant pour être pris au sérieux. Et à court terme, cela fonctionnerait probablement. Mais le simple fait qu'ils aient reconnu le projet piquerait l'intérêt. Certaines personnes décideraient elles-mêmes qu'il n'était ni trop petit ni trop sous-alimenté et commenceraient à l'utiliser.

Un ou deux ans plus tard, le projet représente jusqu'à 50% des fonctionnalités du produit commercial. Les gens commencent à rejoindre le projet en masse. La société commerciale doit maintenant faire quelque chose. Que font-ils? Ils ajoutent plus de fonctionnalités.

Rappelez-vous que le produit commercial répondait déjà à 100% aux besoins des utilisateurs. Alors, quel genre de fonctionnalités pourraient-ils ajouter? Les inutiles. Ils peuvent changer l'apparence de l'interface utilisateur ou ajouter des fonctionnalités en dehors de la gestion du réseau. Quoi qu'il en soit, ce développement coûtera de l'argent et cela commencera à peser sur les marges de l'entreprise.

Enfin, avec une communauté saine et cet afflux de nouveaux utilisateurs, le projet open source atteindra à terme 80% à 90% de ce que le produit commercial fait. Ayant épuisé tous les moyens de générer des revenus, la société commerciale a encore une dernière option: mettre les vis vis à vis de ses clients restants. Trouvez des moyens de les facturer davantage, de tirer le meilleur parti de leur investissement, ce qui finira par faire fuir leurs clients.

Farfelu? Je ne pense pas. Il n'y a que deux exigences principales:

Premièrement, trouvez un marché où l’open source offre une alternative attrayante, telle que la gestion de réseau.

Deuxièmement, construisez une communauté durable autour du projet open source.

Cela semble très plausible. Si vous étiez une entreprise à source fermée, comment concurrenceriez-vous?

Dans la mesure où vous ne pouvez pas rivaliser sur les prix, rivalisez sur tous les autres points de vente du logiciel:

• fonctionnalités
• qualité
• efficacité
• intégration avec d'autres logiciels
• un service
• soutien
• vente directe

En gros, vous faites ce que toutes les autres entreprises font lorsqu'elles sont en concurrence sur les prix: garder le rythme ou changer la donne.

En rendant votre produit meilleur que l'offre open source. C'est ainsi que Photoshop peut rivaliser avec GIMP.

Je pense que l'article que vous avez mentionné est très trompeur, en ce sens qu'il ignore complètement la qualité de l'offre open source. Posez-vous une question légèrement différente mais liée:

Comment une entreprise peut-elle survivre à la vente de logiciels open-source?

Étant moi-même un contributeur assidu à quelques projets open-source, je me sens raisonnablement en droit de lancer quelques tours de boue là où il le mérite.

Rien de ce qui suit ne s’applique aux projets OSS étoiles tels que Linux, Firefox, MySQL ou PostgreSQL, remarquez. Celles-ci sont atypiques, dans la mesure où elles sont appuyées par des entreprises et / ou des codeurs chevronnés.

Quoi qu'il en soit, en ce qui concerne les raisons pour lesquelles le client paiera pour un logiciel:

Les logiciels libres ont tendance à laisser filer les fonctionnalités / les clients paieront pour un logiciel plus simple

Les contributeurs de logiciels libres ont tous leur particularité. Celles-ci finiront par se retrouver dans la base de code. Pour éviter le problème, il faut un leadership extrêmement chevronné, ferme et charismatique, et comme tout autre gars, de nombreux développeurs OSS n'ont pas au moins l'un de ces traits.

Ajoutant l'insulte à la blessure, pour chaque caractéristique non essentielle qui s'introduit, une autre n'en voudra pas et cela entraînera l'ajout d'options. Les codeurs ont tendance à aimer les options, mais du point de vue de l’interface utilisateur, ils constituent un moyen sûr de parvenir à une mort lente et douloureuse de mille coups.

Les utilisateurs finaux veulent des outils simples. Ils ont besoin de faire leur travail sans courbe d'apprentissage ni prise de tête. Ils veulent que leurs outils leur permettent de prendre les bonnes décisions. pas d'options. Si vous pouvez fournir quelque chose de plus simple que l'implémentation OSS autonome, vous obtiendrez des clients payants.

Les logiciels libres ont tendance à être de mauvaise qualité / les clients paieront pour une qualité supérieure

Il n’ya rien de mal à apprendre à coder en contribuant au logiciel libre, remarquez.

Il faut toutefois noter que, pour chaque logiciel de qualité ou bibliothèque de grande qualité soutenu, pour des raisons diverses, par des sociétés et des codeurs chevronnés, il existe un océan de code spaghetti sujet aux bogues, écrit par des codeurs inexpérimentés qui contribuent à un logiciel libre. pour apprendre la programmation, et qui ont peu ou pas d' idée de ce qu'ils font.

WordPress, par exemple, a été créé à partir de B2 (lui-même conçu par un étudiant) par un étudiant. Plusieurs versions et une quantité incalculable de ruban adhésif plus tard, il fait le travail. Mais sous le capot, il s’agit d’un déluge de bugs avec peu ou pas de contrôle de la qualité. (La dernière fois que j'ai essayé, sa propre suite de tests n'a pas réussi.)

Les clients paieront pour des logiciels bien entretenus et testés. Ils essaieront presque tous les trucs gratuits, et beaucoup toléreront même les bugs jusqu’à un certain point. Mais si leurs revenus en dépendent, ils finiront par rechercher un logiciel de meilleure qualité et le payeront.

Les logiciels libres ont tendance à avoir un cycle de développement trop court / les clients paieront pour éviter les tracas

Ceci est inhérent au processus de développement. Les caractéristiques des animaux de compagnie introduites dans la base de code doivent être publiées dans un délai raisonnable. S'ils ne le sont pas, le projet OSS risque de perdre certains de ses contributeurs.

À long terme, toutefois, les entreprises préfèrent les longs cycles de publication. plus c'est long, mieux c'est. C'est moins de planification et moins de travail pour le service informatique. Ce n'est pas grave si les utilisateurs finaux mettent à jour leur navigateur tous les trois mois environ. C'est une histoire complètement différente si vous mettez à niveau des applications critiques.

Une discussion récente a eu lieu sur l’accélération du cycle de publication dans la liste des pirates informatiques de PostgreSQL. L'argument final contre ne concernait pas l'assurance qualité et la nécessité de périodes de test bêta prolongées. Certaines sociétés sautaient déjà une version sur deux, car le cycle de publication actuel (1 an) était déjà trop rapide pour elles.

Contrastez avec WordPress, qui débat de temps en temps d’un cycle de publication de 3 mois, malgré un cycle déjà trop court. (Leurs versions binaires sont, à toutes fins utiles, la version xy0 de chaque version.)

Ayant quelques clients qui utilisent WordPress, je peux vous assurer qu'ils sont plus qu'heureux que je m'occupe d'eux afin de m'assurer que leurs sites ne leur exploseront pas lors de la mise à niveau. Les clients paieront pour ne pas avoir à s'inquiéter de ce genre de tracas.

Les logiciels libres ont tendance à adopter sans scrupule les normes ouvertes / Les clients ont juste besoin que les choses fonctionnent

La balise vidéo HTML5 en est un exemple.

Le cas de Mozilla pour rejeter h.264 est qu'ils veulent un codec open source. Et ils ont absolument raison en ce sens: la dernière chose qu’ils veulent, c’est d’être sur la liste noire des trolls des brevets; alors ils poussent pour Ogg.

Le cas d’Apple pour adopter le h.264, en revanche, est pratique: il est déjà largement pris en charge, et il a une accélération matérielle pour celui-ci (permettant ainsi de prolonger la durée de vie de la batterie des iPhones); Il n'y a rien de tel pour Ogg.

Des millions d'appareils iOS vendus plus tard, les sites inquiets de la diffusion de vidéos à ces utilisateurs iOS prennent en charge le format html5 / h.264. En d'autres termes, les clients ont parlé: ils ne se soucient pas des formats ouverts.

La seule entreprise qui soit satisfaite de l'issue de cette bataille empoisonnée sur les codecs est Adobe: les utilisateurs de Firefox continueront, de facto, à avoir besoin de Flash s'ils veulent lire des vidéos. Si un site majeur passe aux vidéos html5 / h.264 uniquement, un codeur créera rapidement une extension ou un plug-in permettant de convertir les balises vidéo nécessaires en lecteurs vidéo flash. (Il se peut même qu'il existe déjà.) Au nom des normes ouvertes prises en charge (ce qui n'est pas le cas du flash).

Personne n'a jamais été viré pour avoir choisi IBM

C'est une vieille blague de l'industrie, mais il y a une vérité là-dedans: lorsqu'on utilise un budget informatique, on ne se fait pas virer pour avoir choisi ce que ses pairs considèrent comme le meilleur de sa race.

Les grandes entreprises qui n’ont pas le goût de prendre des risques continueront d’acheter des ordinateurs de bureau Microsoft, Office, SAP, etc. même s'il existe des alternatives open source. Un peu comme la merde arrive .

Lorsque les logiciels libres se retrouvent dans de grands environnements d’entreprise, ce n’est généralement pas le cas, car le CTO a compris la situation et a décidé d’utiliser des outils gratuits; il est plutôt canalisé par un tiers qui offre des services (coûteux) en plus.

Je pense que l'essentiel de l'argument, à savoir que "le produit commercial a déjà fourni 100% de ce dont les gens avaient besoin", c’est là où l’argument s’écroule. Aucun produit ne peut prétendre répondre à 100% à ce dont les gens ont besoin, et certainement pas de la manière la plus efficace (en termes d'efficacité de l'opérateur), facile à utiliser et universellement acceptée.

Si une telle chose était possible, il ne resterait bien entendu que le prix. Mais étant donné qu’un objectif "optimal" et une application universelle "optimale" sont impossibles, il restera toujours plus de choses que le seul prix sur lequel rivaliser.

Il y a quelques points positifs dans cet article, mais, encore une fois, le monde réel semble être un bon nombre d'exemples où des entreprises de sources proches s'en sortent très bien. Voici juste quelques

1. Linux contre Windows
2. PHP contre ASP.NET
3. [quelque chose ou autre] vs Visual Studio
4. GIMP contre Photoshop (il a été répondu avant moi, mais j'avais vraiment besoin d'un exemple autre que MS :))
5. vBulletin vs. 30+ autres packs de forum

Le problème avec l'open source est qu'il est ouvert. Si vous avez ce code produit le produit A. Tous vos concurrents ont le même code. Donc, vous passez tout votre temps à écrire un logiciel, une partie de ce logiciel pourrait être confiée à d'autres contributeurs, mais si vous dirigez une entreprise, vous dépensez des ressources et pourtant tout le monde peut venir et commencer à vendre exactement le même que vous avez passé des années développement. La plus grande menace pour une entreprise open source n'est peut-être pas nécessairement une entreprise proche, mais les 5 autres entreprises open source.

D'autre part, si je développe un logiciel à source fermée, vous pouvez copier mes idées, mais je pourrais encore avoir des années d'avance sur vous dans le développement de logiciels et, au moment où vous entrez sur le marché, je pouvais déjà en posséder 90%.

Enfin, en général, les entreprises qui ne partagent pas le code mais qui facturent leurs logiciels génèrent plus de revenus que les projets open source. Dès que ces revenus sont générés, une partie de ceux-ci est réinvestie non pas dans l'ingénierie (ce qui pourrait être gratuit si vous avez beaucoup de contributeurs open source) mais dans le marketing et la promotion du produit et que vous parlez maintenant de millions de dollars. qu'il n'y a pas de travail gratuit.

En fin de compte, voici la formule de votre succès: [innovation en matière d’ingénierie] x [marketing] = profit. Vous pouvez avoir le meilleur produit, mais si personne ne le sait, personne ne l'utilise. Et clairement, si vous construisez quelque chose de nul, aucune publicité ne le sauvera. Je crois que de nombreux projets open source ont toujours eu du mal à [marketing] à pénétrer les marchés de consommation généraux.

La courbe d'apprentissage est un domaine dans lequel la plupart des logiciels open source ne peuvent pas concurrencer les logiciels propriétaires.

Historiquement, j'ai eu du mal à incorporer tous les logiciels Open Source les plus populaires dans mon ensemble d'outils, à l'exception de quelques-uns. Ils sont généralement excellents lorsque je les découvre, mais je ne ressens généralement pas cette frustration initiale avec les logiciels propriétaires.

Je ne suis pas sûr de savoir pourquoi c'est le cas. Je peux cependant dire que je suis plus que disposé à payer pour un logiciel qui fait le travail avec un minimum d'effort de ma part. C'est le but du logiciel après tout.

Rendez-le plus facile à mettre en œuvre que le concours open source et les gens paieront.

Convivialité et fonctionnalités - la seule chose qu'un projet commercial à source fermée aura comme la plupart des projets à source ouverte est la capacité de contrôler une vision forte de ce que le produit est censé être et faire.

Tout cela dépend de la taille / de la complexité, mais un logiciel plus petit pouvant accueillir une seule équipe pourra se concentrer sur le marché auquel il tente de faire appel. (Cet autre exemple - comment BBEdit et TextMate peuvent-ils intéresser un groupe de personnes prêtes à payer pour un éditeur de texte, compte tenu de la disponibilité de jEdit, de gEdit, etc. - 30 $?)

En se concentrant sur les problèmes spécifiques du client. Plusieurs fois, j'ai vu des organisations dépenser des milliers de dollars pour "cette fonctionnalité".

En tant que produit open source, ils doivent se concentrer sur les masses (malheureusement, les masses n'achètent pas ces logiciels 10K +), en tant qu'organisation à but lucratif proche, si vous pouvez satisfaire les besoins de vos clients clés / critiques, une activité accrue suivra.

Comme @SnOrfus l'a déjà mentionné, le service et l'assistance sont essentiels. J'ai vu des millions de fois des organisations préférer le code source fermé au code source ouvert (et même payer un supplément) pour obtenir le confort de pouvoir se procurer quelqu'un du just_in_case!

(cela pourrait être un peu centré sur le client d'entreprise)

La solution commerciale peut à juste titre prétendre que sa fortune est liée au succès de son client. C'est ce que le positionnement du produit est à propos. À quelques exceptions près, les outils open source sont généralement perçus comme un paradis pour les hackers, et non comme une solution ponctuelle centrée sur le client.

Si votre client a besoin de certaines fonctionnalités, vous avez le pouvoir financier de les livrer à temps. Vous avez la capacité de fournir une assistance 24 heures sur 24, 7 jours sur 7, 7 jours sur 7 (et contre paiement), la résolution garantie des problèmes critiques de niveau 0, l'accès à la technologie de nouvelle génération bien avant la communauté open source si vous travaillez avec des constructeurs OEM.

Utilisez-les à votre avantage. Laissez le produit gratuit aussi sur le marché, ne soyez pas hostile. Si tel est le cas, cela élargira le marché - à un moment donné, les utilisateurs du produit gratuit voudront peut-être essayer les cloches et les sifflets de votre solution commerciale.

Par souci de simplicité, résumons les facteurs de succès d’un logiciel en trois "investissements":

(Ici, "investissement" est un terme collectif pour des activités dans lesquelles vous devez payer maintenant, afin de recevoir des revenus plus tard.)

• ventes et marketing
• développement (comprend le code source, la conception du produit / de l'interface utilisateur, la documentation et le matériel de formation. Quantité multipliée par la qualité. Tout produit produit ici peut être reproduit à moindre coût pour un nombre illimité d'utilisateurs)
• services (expertise dans le logiciel et le domaine, et capacité à apporter des améliorations à valeur ajoutée pour chaque client)

L’indicateur de performance clé pour le développement est simple: pouvez-vous développer la même chose mieux et à moindre coût que d’autres. Une partie de cela est un investissement de ressources pure et l'autre est la sagesse de l'architecte et des concepteurs.

Pour les services, avoir accès au code source du produit est un gros bonus. Une entreprise qui n'a pas accès au code source ne peut souvent pas fournir le même niveau de service qu'une autre entreprise qui a accès.

Revenons maintenant à la question du PO: une entreprise à source fermée a-t-elle une stratégie de survie?

L'article cité par OP semble être auto-limitant car il ne considère que deux extrêmes:

• Une entreprise à source fermée développe tout son code source et n'a aucune ligne de code à source ouverte.
• Une entreprise open source adhère pleinement à ce principe et ouvre toutes les lignes de code jamais développées.

Qu'en est-il des terrains d'entente?

• Plusieurs éditeurs de logiciels ont signé des accords de licence croisée pour partager une partie du code source et / ou de l’API? (Dans lequel l'un des partis est axé sur les services.)
• Les entreprises qui utilisent à bon escient des composants open-source sous licence de type BSD (et apportent des contributions en nature), sans ouvrir le code source du produit principal?
• Les entreprises qui fournissent le code source des logiciels en cours d’exécution par le biais d’un système de "prévisualisation de la communauté" limité dans le temps
• "Available-source": entreprises qui fournissent du code source à des clients payants?

Mon point de vue est que les entreprises peuvent survivre si elles adoptent une stratégie de code source partiellement ouverte, partiellement fermée, et si elles réussissent sur les trois fronts (marketing, développement et services). Les entreprises qui adoptent une philosophie de transparence doivent également survivre et devront réussir sur les trois mêmes fronts.

Il y a cependant une mise en garde: si un logiciel est gratuit, les clients le choisiront-ils plutôt que des alternatives, même si le logiciel a mal fonctionné avec certaines métriques?

• ventes et marketing: pouvez-vous promouvoir un produit presque gratuitement grâce au marketing viral?
• développement: un projet open source peut-il obtenir la majeure partie de sa conception, de son développement et de sa documentation auprès de volontaires non rémunérés? Une entreprise peut-elle tirer profit d'un tel projet?
• services: un projet logiciel peut-il révolutionner son domaine logiciel pour le rendre très simple, afin que tout le monde puisse devenir un expert instantané, en abaissant à zéro la barrière d’entrée?

Le projet open source poursuit le projet commercial en termes de fonctionnalités. Cela laisse une sorte d'arbitrage temporel à la société commerciale pour concurrencer sur les caractéristiques. Ils doivent se battre pour implémenter constamment des fonctionnalités afin de conserver un avantage sur la société open source. C'est cher, mais ça peut marcher.

Comme d'autres personnes l'ont mentionné, les fonctionnalités peuvent inclure la documentation et la facilité d'utilisation.

La société peut essayer d’instaurer un verrouillage du vendeur, mais cela ne fait que ralentir les pertes; cela ne vous rapporte aucun client.

Cela laisse deux moyens principaux de conserver des parts de marché: le support et l'exploitation de la méfiance des gestionnaires vis-à-vis des logiciels open source. Malheureusement, ce dernier va vous amener assez loin. Le support de vente fonctionnera, cependant, et même lorsque le projet open source s’accumulera suffisamment pour obtenir le soutien d’une entreprise, la solution commerciale aura un avantage en étant le titulaire du poste, en ayant plus d’expérience et en ayant l’impression qu’ils le sont. plus familier avec leur produit.

À long terme, vous risquez d'être foutu, mais cela peut faire du "court terme" un "avenir prévisible".

Une chose que personne d’autre n’a mentionnée est la documentation. Un grand nombre de programmes n'a pas vraiment besoin de beaucoup pour être utilisable (Firefox, Openoffice), mais si vous écrivez une bibliothèque, un serveur, un langage de programmation ou tout simplement un programme très compliqué, la documentation peut faire ressortir la vôtre.

L’amélioration de la documentation peut réduire la frustration de vos utilisateurs (les incitant ainsi à continuer à utiliser votre produit et à suggérer de l’utiliser ultérieurement), et vous pouvez annoncer que cet argent est bien dépensé, car vos clients ne passeront pas autant de temps à coder (et temps == argent).

Ce n'est pas nécessairement open source contre source fermée cependant - à peu près tout est mal documenté. Il se peut que votre concurrent soit dans 1% des projets qui documentent bien les choses, mais c'est peu probable;)

Tout simplement, le truc est de continuer à redéfinir 100%. FOSS n'a tout simplement pas la même ampleur et la même main-d'œuvre que les projets commerciaux, et il existe des limites à la concurrence étroite avec un produit existant. Les entreprises à source fermée utilisent des points d’interface utilisateur, ce qui rend impossible l’utilisation d’un produit concurrent en raison de différents raccourcis clavier, par exemple. En outre, ils continuent d’ajouter des fonctionnalités majeures qu’un concurrent FOSS ne pourrait tout simplement jamais prendre en compte. Par exemple, considérons Visual Studio. C'était juste un IDE C ++, mais ils ont ensuite commencé à regrouper de nouveaux langages et frameworks, tels que .NET. Ou Visual Studio 2010, qui regroupe une bibliothèque de threads de qualité commerciale (comme dans Intel vend une solution autonome équivalente) pour C ++. Les logiciels libres ne peuvent tout simplement pas suivre ce genre de développement et souvent de fiabilité.

Ciblez les marchés traditionnels des entreprises et gagnez en popularité.

Pour beaucoup de grandes entreprises traditionnelles, cela se résume à trois choses:

• un fournisseur avec lequel ils peuvent conclure un contrat obligatoire (capacités et fiabilité)
• un fournisseur avec lequel ils peuvent appliquer contractuellement un accord de niveau de service spécifique (qualité du support)
• Gartner reviews (c'est l'équivalent moderne de "personne ne se fait virer pour avoir choisi IBM)

Tous les trois sont suivis aveuglément, et pas particulièrement valables. Les problèmes de capacité sont toujours survendus, les ANS ont toujours une excuse et Gartner n’enquête que sur les types de personnes qui l’écoutent, mais lorsque vous êtes un cadre moyen dans un corp qui compte de nombreux cadres supérieurs qui ont des problèmes avec la direction Lorsque la haute direction apprend enfin qu’une décision irréfléchie a coûté une grosse somme d’argent, vous avez besoin de la documentation d’un tiers qui étaye votre position si vous souhaitez sauvegarder votre travail. Même si vous savez très bien que d’un point de vue technique, vous jetez de grosses sommes d’argent dans les toilettes, cela ne vaut pas la peine d’essayer de faire ce qui est juste.

Combien de mauvaises utilisations de SAP ou de SharePoint avez-vous vu dans le secteur? Combien de ceux-ci auraient été meilleurs s'ils avaient été faits sur quelque chose qui conviendrait mieux, mais pas un grand nom de l'industrie?

J'utilise beaucoup d'outils Microsoft et j'ai un compte MSDN, mais honnêtement, les gens de MS sur Twitter m'apportent une meilleure aide que le centre de téléphonie MSDN. Je ne peux pas imaginer que les personnes derrière le projet open source et les personnes qui en bénéficieront seront plus mal à l’aide que les personnes ne prenant pas en charge le support technique dans leurs temps libres, mais cela n’entre pas dans l’équation Responsabilité / Gartner.

Comme SnOrfus a dit vendre les fonctionnalités, nous le faisons.

Ex: nous développons des plugins avec des fonctionnalités communes et le rendons gratuit à télécharger sur le site Wordpress. En même temps, nous avons notre plugin de version payante qui a des fonctionnalités professionnelles.

Cela vous aide à présenter votre produit à une masse de gens, à savoir le pouvoir de l'open source et des gens.