Discussion sur l'Open Source

[Paul MONFILS]

plusieurs interventions que j'ai trouvées constructives

Merci

 

pourrait-on considérer par exemple qu'un module payant engage la responsabilité de son vendeur, alors qu'un gratuit téléchargé à la volée au coin d'un forum n'engage que celui qui l'utilisera? Ou est-ce vraiment trop simpliste comme raisonnement?

La réponse dans les deux cas est: le développeur est juridiquement responsable !

Faute de temps dans l'immédiat (réunion oblige) je reviens sur différents points que vous soulevez Daniel dès que possible. Merci de votre intervention car il y a mine de rien matière à apporter des infos.

[Paul MONFILS]

En attendant les retardataires à la réunion, je reviens un peu avant d'approfondir:

Daniel, et d'autres aussi auparavant, vous soulevez donc trois notions importantes:

- l'open source: la notion "philosophique", l'interprétation de licences et celle de "business model"

- le concept juridique du libre de droit et de la différentiation ou non des droits consentis en matière de licence

- la responsabilité juridique d'un développeur, que le module soit gratuit ou payant

Sur ces 3 points donc je reviendrai dans la journée...

[Raphaël Malié]

@daniel3000 : dans ce cas je veux bien que vous me communiquiez l'adresse de votre site, que je puisse aller y récupérer gratuitement les articles qui m'intéressent

L'argument massue n'est absolument pas ce que vous citez. L'argument massue c'est qu'Open Source et gratuité sont deux concepts bien distincts. Il n'y a pas d'intérêt à débattre tant que ce fait établi est mis en cause.

[Paul MONFILS]

Je reviens donc pour reprendre mes 3 points donnés précédemment:

- je vais parler de la notion d'open source. Pour cela je vais tirer mes propos du livre blanc Smile. On se rend compte que nombre de personnes ont du mal à saisir la notion d'open source et d'autres termes qui se mélangent.

Ce que l'on appelle le code source est la version d’un programme qui est lisible et intelligible pour l’homme. C’est le code source qui est écrit par l’informaticien, le programmeur, et qui pourra être relu et modifié par d’autres. Les programmes peuvent ensuite être compilés, ce qui produit le code objet, ou binaire, ou encore exécutable, qui lui n’est pas compréhensible.

 

 

Un logiciel libre, ou logiciel open source, est un programme dont le code source est distribué et peut être utilisé, copié, étudié, modifié et redistribué sans restriction.

 

Notons qu’il existe des langages informatiques interprétés, tels le PHP, qui n’existent pas autrement que sous forme de code source. Mais même lorsque le code source est disponible, il n’est pas toujours autorisé de le modifier. Ce sont les termes de la licence, concédée par l’auteur ou le détenteur des droits, qui précisent s’il est permis ou non de modifier le code, de le réutiliser, de le redistribuer, et sous quelles conditions.

 

Logiciel libre est la juste traduction française de free software, l’appellation lancée par Richard Stallman et défendue par la Free Software Foundation, la FSF.

 

Open source est l’appellation de l’Open Source Initiative, qui édicte sur le site opensource.org les conditions que doit satisfaire une licence pour se dire open source.

 

Le logiciel libre est défini par quatre libertés fondamentales : exécuter le programme, l’étudier, l’adapter, le redistribuer.

 

Il faut souligner que le libre accès au code source est simplement rendu nécessaire par ces libertés fondamentales, et non une fin en soi.

 

Le logiciel open source se définit par les 10 articles de l’open source definition, sur laquelle nous reviendrons plus loin.

Les deux appellations sont presque équivalentes, mais correspondent à des écoles de pensées différentes. Aucune n’acceptant d’être englobée par l’autre, les américains utilisent parfois le terme de FOSS pour « Free and Open Source Software », ou encore FLOSS pour « Free/Libre and Open Source Software ».

 

Nous avons estimé qu’utiliser « FLOSS » dans tout le corps de ce post serait pesant pour ceux qui lisent déjà ce sujet qui s'étale en longueur... et prenons donc le parti d’utiliser le terme open source. Notons toutefois que FLOSS est le terme officiel adopté par la commission européenne.

 

Quelle est la philosophie de l'open source ?

 

- Une liberté fondamentale

Pour Richard Matthew Stallman, le père de la Free Software Foundation (1985), « RMS » pour les intimes, le logiciel libre est avant tout affaire de liberté. La liberté que doit avoir chaque individu d’utiliser, modifier, et redistribuer n’importe quel programme. Une liberté aussi fondamentale que la liberté d’expression. Et indissociable d’autres valeurs, d’éthique et de responsabilité sociale.

Dans cette logique, un logiciel non libre, « propriétaire » donc, porte atteinte à cette liberté fondamentale. Le logiciel libre n’est donc pas une simple alternative, et encore moins le choix d’un business model parmi d’autres. Le logiciel propriétaire est « privateur » dans le sens où il prive de liberté, et il est en ce sens intolérable. Il s’agit bel et bien une lutte du bien contre le mal.

On pourrait sourire de ce manichéisme, mais lorsque l’on voit l’extraordinaire patrimoine de logiciels que le mouvement initiée par Stallman a mis à disposition de tous, on se doit d’être surtout admiratif et reconnaissant. On ne fait pas une révolution avec des idées molles, et il fallait l’intransigeance de Stallman, pour créer une vraie rupture, et un mouvement de pensée profond, où la liberté va de pair avec des valeurs de solidarité sociale et d’entraide.

 

- Un modèle de développement

Pour Eric Raymond, il ne s’agit guère d’éthique, ou même de philosophie, il est question avant tout de démontrer la supériorité des logiciels réalisés selon un modèle de développement open source communautaire, et de les faire entrer dans la sphère économique. Pour Eric Raymond, le dogmatisme de la FSF ne joue pas en faveur du mouvement, et ce sont des logiciels de qualité supérieure, plus que les valeurs éthiques, qui imposeront l’open source.

Avec Bruce Perens, il fonde l’Open Source Initiative en 1998, pour promouvoir l’open source. Le mouvement « open source » apparaît à certain comme une opération de marketing en faveur du logiciel libre. Mais pour Richard Stallman, il n’est pas permis de jeter au passage les valeurs fondatrices, en particulier de liberté. Des années plus tard, la cicatrice de cette scission n’est pas refermée entre logiciel libre et open source, en démontre par exemple ce sujet sur le forum. Et l’on ne peut choisir une appellation plutôt qu’une autre sans s’attirer les foudres de l’un des camps. Dans la pratique, Stallman convient que "les deux termes décrivent pratiquement la même catégorie de logiciel. Mais ils représentent des vues basées sur des valeurs fondamentalement différentes."

 

- Un patrimoine de l’humanité

Enfin, vous trouverez ici la propre vision de l’open source, non pas tant affaire de liberté, mais de progrès et de patrimoine. Voici le texte d’une tribune publiée en 2006, et qui présente ce point de vue:

"Nous sommes des nains sur les épaules de géants". C’est dans le domaine des sciences que l’on entend cette pensée. Et en effet, les savants d’aujourd’hui ne sont pas plus intelligents que ceux d’hier, mais ils bénéficient, dès leur formation, de siècles de science accumulée et c’est sur ce socle immense construit par Newton, Einstein et les autres, qu’ils apportent leurs petites pierres.

L’informatique n’est pas exactement une science. Mais doit-elle pour autant tout reconstruire à chaque génération ? Si c’était le cas, elle serait condamnée à toucher rapidement ses limites. Les informaticiens d’aujourd’hui sont-ils plus doués que ceux d’hier ? Certainement pas. Ont ils appris plus de choses en cours ? Un peu sans doute. Mais cela ne suffirait pas à s’élancer plus loin.

Car si, en sciences, le patrimoine est entièrement dans le savoir, en informatique, il y a deux patrimoines : la connaissance d’une part, le code source d’autre part. La connaissance progresse lentement et il y a peu de savoirs fondamentaux pour bâtir, disons, Mac OS X ou bien Eclipse, qui étaient inconnus il y a 15 ans. Si l’informatique progresse, c’est plus par le patrimoine de code source que par la connaissance, c’est-à-dire que l’on peut s’appuyer aujourd’hui sur un immense socle de code source.

 

Dans les premiers temps, les informaticiens devaient tout créer, pratiquement pour chaque programme. Puis, les systèmes d’exploitation ont amené un premier niveau de socle, qui est devenu plus sophistiqué au fil des années, et les langages de haut niveau ont amené des bibliothèques de plus en plus riches.

Sur ce socle élémentaire, nous avons ajouté différents socles de développement, des frameworks, qui constituent une seconde couche. Et ce n’est pas tout : nous disposons aussi d’une quantité de composants de haut niveau, que nous pouvons assembler pour construire des applications nouvelles. Au total, 90% du code déroulé dans ces applications sera issu, soit du système d’exploitation, soit des frameworks, soit des composants. Et nous n’aurons réellement développé que les 10% de valeur ajoutée spécifique.

C’est un constat important : l’informatique progresse essentiellement parce que le socle de code qui constitue notre patrimoine s’agrandit.

Si, dans un effort gigantesque, je réalise un programme nouveau, représentant disons un million de lignes de code originales, que ce programme répond à un besoin et qu’il est un succès commercial, c’est certes une belle aventure, qui m’enrichira peut-être et sera utile à mes clients.

Mais je n’aurai pas réellement fait progresser l’informatique d’un pouce, car trois ans après moi, si un autre veut aller plus loin dans cette voie, pour faire un meilleur programme sans disposer du mien, il lui faudra repartir d’où j’étais parti, ré-écrire mon premier million de lignes de code, pour enfin y ajouter 200 000 lignes qui l’amèneront un peu plus loin. Ne pouvant grimper sur mes épaules, il a les deux pieds dans la même boue que moi, et n'a d'autre choix que d'être géant lui-même. C’est la dimension humaniste de l’open source que de considérer que nous apportons chacun notre pierre, ajoutant à ce patrimoine commun, qui nous permettra d’aller plus loin. (...)

 

 

Ensuite abordons la notion du libre. « Free » voulant dire littéralement à la fois « gratuit » et « libre », les tenants du free software s’évertuent à faire comprendre qu’il s’agit bien de liberté et non de gratuité, selon la formule « free as in ‘free speech’ and ‘free market’, not as in ‘free beer’ ». En français, nous n’avons pas cette ambiguïté, mais nous avons gardé la formule « logiciel libre ne signifie pas gratuit ». Et de cette formule, certains comprennent qu’un logiciel libre peut être payant. Ce n’est pas strictement faux, mais presque. Expliquons. Rien en effet, dans les licences open source, n’interdit de faire payer la distribution du logiciel. Mais celui à qui vous le distribuez sera autorisé à le dupliquer et le redistribuer gratuitement s’il le souhaite. On voit qu’il est bien difficile de vendre quelque chose que d’autres peuvent donner !

Donc dans la pratique, il faut retenir que un logiciel open source est bel et bien gratuit, d’acquisition comme d’utilisation, du point de vue de sa licence.

 

Bien sûr, les bénéfices économiques sont parmi les premières raisons dans le choix de solutions open source. Même si « libre ne signifie pas gratuit », ces solutions ont toujours un coût de possession sensiblement moins élevé que leurs équivalents propriétaires. D’autant que les prix de prestations tendent aussi à être moins élevés, car l’ouverture du produit facilite la diffusion de la connaissance. Mais au fur et à mesure que ces solutions arrivent à maturité, le moindre coût n’est plus le premier critère de choix.

Les principaux arguments sont alors :

La non-dépendance, ou moindre dépendance, par rapport à un éditeur. On sait que changer d’outil peut coûter très cher, et les éditeurs peuvent être tentés de profiter de la vache à lait que constituent ces clients devenus captifs. En anglais, on parle de vendor lock-in, le verrouillage par le fournisseur.

L’ouverture est également un argument de poids. Les solutions open source sont en général plus respectueuses des standards, et plus ouvertes vers l’ajout de modules d’extension.

La pérennité est un autre critère de choix fort.

Et la qualité finalement, car dans beaucoup de domaines les solutions open source sont réellement, objectivement, supérieures. Le très grand nombre de déploiements et donc de retours d’expérience, mais aussi leur modèle de développement et leur intégration de composants de haut niveau, permet à beaucoup de surclasser les produits propriétaires souvent vieillissants.

A quoi on peut ajouter le plaisir, pour les informaticiens, d’utiliser des programmes dont ils peuvent acquérir une totale maîtrise, sans barrière ni technique ni juridique.

Comme nous le verrons, cela n’empêche pas qu’il soit accompagné d’une offre de services payants : intégration, support, formations, développements complémentaires, voire même assurance juridique. De sorte que son « coût total de possession » est rarement nul, même s’il est presque toujours inférieur à celui d’une solution propriétaire équivalente.

 

 

En matière de pérennité, les solutions open source n’ont pas une garantie d’éternelle jouvence. Elles peuvent mourir, aussi, mais de mort lente ! Le pire qu’il puisse arriver pour une solution open source est une désaffection progressive de la part des communautés, généralement au profit d’une solution plus prometteuse. Ainsi, il est possible qu’il faille un jour changer de produit. Mais du moins le phénomène est toujours lent, et le client a le temps d’organiser la migration.

Il faut souligner aussi que, même si l’éditeur original était un jour défaillant, il resterait toujours possible pour une communauté de reprendre en main le produit et ses évolutions, c’est le principe des licences open source.

La notoriété, l’envergure des déploiements, la dynamique du développement et de la communauté, ces critères de pérennité sont relativement facile à évaluer, et une solution open source leader offre une garantie de pérennité supérieure à la majorité des solutions propriétaires.

 

 

Un mot également sur la question de l’ouverture. La possibilité de faire des modifications dans les sources est fondamentale sur le plan théorique, mais souvent risquée sur le plan pratique. Ce n’est donc pas en ces termes qu’il faut apprécier l’ouverture, mais plutôt dans la capacité à accepter des extensions, ou à s’interfacer à d’autres applications.

Sur le fond, il faut comprendre qu’un éditeur à vocation commerciale n’a pas que des intérêts convergents avec ceux de ses clients. Certes, il évolue dans un marché concurrentiel, et son produit doit être au niveau de ses concurrents.

Mais une fois sa position bien assise, l’éditeur peut faire l’analyse que :

Son produit doit être performant, mais pas trop, car s’il faut plus de serveurs, ce sera davantage de licences vendues.

Son produit doit être robuste, mais pas trop, car il faut continuer à vendre du support.

Son produit doit être ouvert, mais pas trop, pour garder la maîtrise du client.

Nous ne disons pas que les éditeurs propriétaires seraient machiavéliques au point de dégrader ces qualités dans leur produit, nous disons seulement que la priorité stratégique n’est pas nécessairement mise sur ces qualités.

En matière d’ouverture, enfin, il faut souligner que le logiciel propriétaire n’est pas la seule manière d’enfermer un client. Les formats de documents sont aussi une arme puissante pour parvenir au verrouillage du client. Ces dernières années, on a pu voir une forte prise de conscience de l’importance des formats ouverts, c’est à dire à la fois documentés, et d’utilisation libre. Ils sont à la fois la condition de l’indépendance, mais aussi de la pérennité des documents, et de l’interopérabilité des applications partageant ces document.

 

la suite dans le prochain post.

[Paul MONFILS]

Maîtriser les sources : un droit, non un devoir.

Il faut souligner, car c’est souvent mal compris, qu’il n’est nullement nécessaire de maîtriser les sources d’un produit open source, pour le déployer, l’utiliser et en tirer bénéfice. Ni de les maîtriser, ni de les regarder, ni même de les télécharger.

Il y a quelques années encore, certains produits open source s’attachaient à ne diffuser que les sources, obligeant l’utilisateur à recompiler et générer son programme. Cette démarche un peu extrémiste est aujourd’hui abandonnée car elle nuit à la diffusion de l’open source.

Prendre connaissance des sources est un droit et non un devoir.

De même, modifier les sources est un droit fondamental, mais dans beaucoup de cas c’est une chose qui n’est pas recommandée. Cela pour plusieurs raisons :

- Il y a un risque important de fragiliser le produit, parce que votre code sera moins bien testé que le reste, et que vous l’aurez écrit avec une moindre maîtrise de l’ensemble.

- Sur des produits d’envergure, apporter des modifications demande un grand investissement, une grande implication, et donc un budget sérieux.

- Votre version modifiée est donc un fork, une version alternative, du produit. Elle ne bénéficiera pas, ou plus difficilement, du support tant éditeur que communautaire, et il faudra réintroduire vos modifications dans les nouvelles versions pour pouvoir en bénéficier.

Dans une majorité de cas, ces raisons l’emportent. Pourtant, si elles devaient bloquer toute forme de contribution, la vitalité de l’open source serait compromise. Ce qu’il faut, c’est que chacun, développeur indépendant ou organisation, mesure l’investissement qu’il peut faire sur un projet, s’y implique en échangeant abondamment avec les autres développeurs du projet, et effectue ses modifications non pas dans son coin, mais dans le référentiel commun. C’est à dire qu’il est tout à fait souhaitable d’enrichir le produit au sein de la communauté ou en liaison avec l’éditeur, mais qu’il n’est en général pas souhaitable de le faire autrement.

 

Qu'en est-il des pseudo-open source ? En théorie, il suffit de proposer ses sources sous une licence agréée pour se revendiquer logiciel open source. Pour les utilisateurs toutefois, il faut se défier des produits pseudo-open-source.

Il arrive couramment que des éditeurs de solutions propriétaires en échec sur le marché, particulièrement face à la montée en puissance de solutions concurrentes open source, prennent un ultime revirement stratégique avant de disparaître, en déclarant que leur produit devient open source. Ils diffusent les sources avec plus ou moins de bonne volonté, et envoient leurs commerciaux clamer sur le marché qu’ils sont désormais aussi ouverts que leurs concurrents open source. Mais le cœur n’y est pas, et ils ont la ferme résolution de ne laisser personne prendre la maîtrise de leur code, et de garder la mainmise sur la totalité des déploiements.

Pour les clients, ces solutions sont la pire des voies car ils n’auront au bout du compte aucun des bénéfices de l’open source, et en particulier subiront le même verrouillage, le vendor lock-in, qu’avec une solution propriétaire. Mais plus grave que ça : l’expérience montre que ces solutions disparaissent presque toujours dans l’année qui suit.

 

Et en matière de licence ?

Copyright et licences, principes élémentaires

Les programmes open source ne sont pas des programmes sans licences. C’est au contraire leur licence qui les fait open source. Ils ne sont pas non plus dans le domaine public, c’est à dire n’appartenant à personne en particulier.

Lorsqu’un développeur écrit un programme, il en détient les droits d’auteur, le copyright. Dans certains cas, ce peut être l’entreprise qui l’emploie qui en détient les droits. Et ce copyright peut être vendu, comme bien immatériel, d’une entreprise à une autre. Le détenteur du copyright est libre de définir l’utilisation qui peut être faite de son programme :

Il peut le garder pour lui, en interdire l’utilisation à qui que ce soit.

Il peut vendre ses droits à un tiers, personne physique ou morale.

Il peut utiliser son droit d’auteur pour préciser les conditions qu’il pose à l’utilisation de son programme. Il écrit ces conditions dans les termes de la licence d’utilisation.

A noter qu’en droit français, il n’est pas aisé d’abandonner ses droits et de mettre son programme dans le domaine public de manière irréversible.

Il faut bien expliquer aussi que ce n’est pas la diffusion des sources qui fait qu’un programme est open source, c’est le droit, inscrit dans la licence, de les utiliser, de les modifier et de les redistribuer librement.

Il est donc important de bien assimiler la logique suivante : à la base de l’open source il y a la licence, et la licence n’existe qu’à partir du droit d’auteur.

Ainsi tous les logiciels open source ont un propriétaire, ils ne sont pas « à personne ». Dans certains cas, ce propriétaire peut être une fondation à but non lucratif, ou bien ce peut être une entreprise commerciale ordinaire. Le détenteur des droits est libre de fixer les conditions de licences, il est libre d’en changer même, et il est libre d’y faire des aménagements ou exceptions, ou de diffuser à certains selon une licence, à d’autres selon une autre licence.

Celui qui reçoit le programme, en revanche, n’est pas libre. Il est lié par les termes de la licence. Certes il n’a pas signé de contrat, mais la licence lui a été bien énoncée, et elle stipule qu’il n’a le droit d’utiliser le programme qu’à telles et telles conditions. S’il refuse ces conditions, il n’a pas le droit d’utiliser le programme.

 

Mentions élémentaires des licences: toutes les licences open source ont en commun quelques clauses de bon sens :

L’identification claire du propriétaire du copyright, y compris au travers des copies ou travaux dérivés.

L’obligation de conserver la notice de licence en l’état, sur le programme et les travaux dérivés. C’est bien sûr une nécessité technique : inutile de définir des termes de licence s’ils sont évacués dès la première copie.

La protection de l’auteur vis à vis des utilisateurs de son programme, ses éventuels défauts et les conséquences de ces défauts : « ce programme est fourni ‘en l’état’ (« as is »)… ». C’est bien le moins qui puisse être exigé : l’auteur vous laisse utiliser librement son travail, vous n’allez pas quand même lui réclamer des dommages et intérêts.

A noter que dans certains pays, la distribution payante d’un programme entraîne des droits inaliénables. D’une manière générale, la licence ne peut être contraire au droit national. C’est pourquoi elle dit “Si vous ne pouvez pas distribuer le programme en satisfaisant à la fois vos obligations liées à licence et d’autres obligations applicables, alors vous ne pouvez pas distribuer le programme du tout ».

C’est à dire que soit l’on peut respecter les lois nationales et la licence à la fois, soit on est dans l’interdiction de distribuer le programme sous ladite licence.

 

Définition d'un logiciel libre: comme dit dans mon post précédent, le logiciel libre se définit par le respect de quatre libertés fondamentales :

exécuter le programme,

étudier le programme et l’adapter selon son besoin (ce qui implique bien sûr l’accès au code source),

redistribuer le programme pour aider son prochain,

et enfin améliorer le programme et distribuer ces améliorations au public (ce qui de même implique le libre l’accès aux sources).

La finalité première est la liberté, l’accès au source n’est qu’un pré requis pour respecter cette liberté.

Définition d'une licence open source:

L’OSI, Open Source Initiative, a édicté une définition précise de ce que signifie open source, une définition qui est aujourd’hui reconnue de manière à peu près universelle. Avoir une définition officielle précise est très important, une licence ne doit pas pouvoir être plus ou moins open source : elle l’est ou ne l’est pas, les choses doivent être claires. Et le site de l’OSI, opensource.org, indique aussi quelles sont les principales licences qui se conforment à cette définition. On y retrouve bien entendu les licences bien connues, à commencer par la GPL, LGPL, GPL-V3, AGPL, etc.

 

Mais portons-nous sur les licences qui concernent Prestashop.

Le thème standard et les modules de PrestaShop sont publiés sous licence AFL 3.0. L’intégralité du logiciel PrestaShop, à l’exception de ces éléments et des bibliothèques tierces, sont sous licence OSL 3.0.

Mais qu'est-ce ?

AFL 3.0 : The Academic Free License 3.0

 

Cette licence s'applique à toute œuvre originale de l'auteur dont le propriétaire a placé l'avis de licences suivante à côté du copyright de l'œuvre originale: Sous licence libre académique License Version 3.0

Principaux articles consultables ici

 

L'Academic Free License (AFL) est une licence libre écrite en 2002 par Lawrence E. Rosen, conseiller général de l'Open Source Initiative. Elle en est donc a sa V3. Cette licence est proche des licences BSD, MIT, UoI/NCSA et Apache qui autorisent l'utilisation dans le cadre de logiciels propriétaires. Elle est considérée comme non compatible avec GPL par la Free Software Foundation (FSF).

Elle a pour but de clarifier certains points par rapport à ces autres licences. Un de ces points est que celui qui appose cette licence sur son code affirme qu'il n'a pas enfreint une quelquonque liberté intellectuelle donc se porte garant vis-à-vis de son travail, il doit aussi garantir qu'il n'y a pas de brevet enfreint non plus.

OSL 3.0: The Open Software License 3.0

Il s'agit d'une licence de logiciel libre incompatible avec la GNU GPL.

Principaux articles consultables ici

Les versions récentes de l'Open Software License ont une clause qui requiert de la part des distributeurs d'essayer d'obtenir un agrément explicite à la licence. Cela signifie que distribuer des logiciels sous licences OSL sur des sites FTP ordinaires, envoyer des correctifs sur une liste de diffusion ou stocker le logiciel dans un système de contrôle de version ordinaire, est une violation de la licence et vous rend passible de révocation de cette licence. Par conséquent, l'Open Software License rend très difficile de développer des logiciels en utilisant les outils courants pour les logiciels libres.

 

La suite (Business Model et responsabilité juridique d'un développeur) dans le prochain post.

[Paul MONFILS]

Business Model

Ce qu’on appelle business model, ce sont les principes de fonctionnement qui assurent la rentabilité d’une société.

La question est souvent posée par les néophytes incrédules : Mais si c’est gratuit, alors comment ça peut marcher, il faut bien que quelqu’un paye à un moment ? Et de fait, tout n’est pas gratuit dans l’open source, et il y a une vraie économie de l’open source, qui a ses particularités.

Nous étudions ici les 4 typologies d’acteurs de l’open source :

Fondations

Distributeurs

Editeurs

Prestataires

 

Je vais m'intéresser aux distributeurs, éditeurs et prestataires.

Les distributeurs distribuent essentiellement des produits dont ils ne sont pas détenteurs des droits. Ils n’ont donc pas le choix de proposer telle ou telle licence, ou bien une licence GPL et une licence commerciale comme le font certains éditeurs : c’est le détenteur des droits qui décide de la licence. Les distributeurs open source diffusent une majorité de produits sous GPL, et quelques produits sous BSD ou d’autres licences. Certains sont aussi éditeurs de quelques produits de leur distribution.

 

Les éditeurs open source. L’éditeur, c’est celui qui détient les droits du produit, en assure le développement, la promotion, la diffusion et le support. Dans un premier temps, les seuls acteurs commerciaux de l’open source étaient des distributeurs plus que des éditeurs. C’est MySql qui a ouvert la voie de la logique de l’éditeur open source, et depuis quelques années, ce modèle a donné naissance à de nombreux nouveaux acteurs, particulièrement dynamiques.

Les éditeurs open source sont des sociétés commerciales ordinaires, c’est à dire à but lucratif. Comme un éditeur ordinaire, elles investissent massivement dans le développement de leur produit, et parfois également dans sa promotion, son marketing. La seule différence est que le produit est diffusé sous licence open source, ou parfois sous double licence.

Pourquoi choisissent-ils ce modèle ? Au delà de l’adhésion aux valeurs de l’open source, ils font sans doute l’analyse que l’open source est devenu le seul moyen de percer dans un marché prisonnier de quelques oligopoles. Un peu à la manière des compagnies aériennes low-cost, ces nouveaux acteurs amènent un business model légèrement différent, de nature à casser les positions acquises.

Business model de l’éditeur open source: les éditeurs open source ont trois types de revenus :

Vente de licences.

Vente de support.

Vente de prestations.

Auxquels s’ajoutent dans certains cas des revenus issus de leurs intégrateurs partenaires : partenariat payant pour certains, ou commission sur l’apport d’affaires, lorsque des prospects sont dirigés vers des partenaires.

Et bien sûr, au chapitre des dépenses, on trouve :

Le développement produit.

Le support.

Le commerce et le marketing.

Les éditeurs bénéficient aussi de l’open source au niveau des coûts : en pouvant s’appuyer sur l’extraordinaire patrimoine de code déjà disponible sous licence open source, ils font d’importantes économies de développement.

 

« Vendre des licences » et « open source » semble une contradiction. Effectivement, même si ce n’est pas interdit, aucun éditeur ne vendrait une simple licence GPL.

Mais il y a plusieurs cas de figure de double licences possibles :

1. Sortir de la GPL

Le premier est une licence non open source, propriétaire donc, qui permet au client de ne pas être tenu par les obligations de la licence GPL. En particulier si le client veut distribuer une œuvre dérivée utilisant le programme, et ne souhaite pas diffuser ses sources, il lui faudra acquérir une licence commerciale. Des éditeurs comme eZ Systems ou MySql ont choisi ce modèle.

Pour des applicatifs de haut niveau, par exemple le CMS eZ Publish, ce n’est en général pas une source de revenus importante car la finalité est de faire un site et rarement de faire un produit. Mais dans le cas de MySql, la vente de licences représente plus de la moitié du CA.

2. Modules complémentaires payants

Le second cas de figure est celui où l’éditeur propose des modules complémentaires à l’application principale, ces modules étant exclusivement sous licence commerciale. Selon les cas, la partie open source pourra être plus ou moins complète. Mais si elle est trop légère, et donne l’impression d’être un simple appât pour ferrer le pigeon, elle sera rejetée. Si l’application open source est de qualité, et que les modules payants sont optionnels, le modèle peut tenir la route. On peut citer Talend et Pentaho, comme éditeurs ayant choisi ce modèle.

3. Dépendance entre le support et la licence

Le troisième cas est celui où l’éditeur crée une dépendance entre son offre de support et la licence commerciale. Dans ce cas l’éditeur ne propose aucun support, même payant, sur la version open source. Pour avoir du support, il est nécessaire de choisir la licence commerciale. C’est le cas de l’éditeur Alfresco.

 

Les éditeurs peuvent donc également proposer des prestations autour de leurs produits, dont ils sont nécessairement les meilleurs experts : conseil, audit, définition d’architecture, analyse de problèmes, formations.

Ces prestations sont également proposées par les prestataires intégrateurs, de sorte qu’une ligne de partage est en général trouvée :

L’éditeur assure les prestations qui requièrent la plus grande expertise, et sont peu liées au contexte spécifique du client.

L’intégrateur assure les prestations de proximité, liées à un déploiement et un environnement spécifique.

Dans certains cas, les clients peuvent également financer des développement du produit qui visent à mieux couvrir son besoin spécifique, mais pourront être utiles à d’autres clients, et donc être intégrés au produit.

 

Loi des grands nombres

Pour prospérer, les éditeurs open source doivent être dans une logique de grands nombres, à la manière de MySql : le fait que 10 millions d’utilisateurs ne payent rien à MySql AB n’est pas problématique si sur ce nombre, il en reste 10 000 qui ont des utilisations suffisamment stratégiques, et souhaiteront disposer d’un support d’éditeur, avec délai d’intervention garanti. Le pourcentage de clients qui feront appel au support éditeur dépend de la typologie de produit. Pour un produit grand public, par exemple un antivirus open source, il sera bien difficile de faire payer du support à beaucoup, ou de vendre sa version payante. Pour un produit dont la vocation est fortement B2B, par exemple une Gestion Electronique de Documents, la part des clients demandeurs de support sera naturellement plus grande.

 

Contributions communautaires

Les éditeurs open source comptent en général assez peu sur les apports communautaires, du moins sur le cœur de leur produit. Ils les acceptent car c’est dans la logique de l’open source, mais ne les encouragent guère et l’on peut penser qu’il ne leur déplait pas de garder la maîtrise de leur produit.

A noter que si son morceau de code est accepté, le contributeur devra généralement signer un accord spécifique qui permet à l’éditeur de disposer librement de son code. C’est assez naturel, car si chaque contributeur pouvait spécifier ses propres conditions de licence, le produit final serait un enchevêtrement de licences indémêlables.

Afin de bénéficier d’une dynamique communautaire, tout en conservant la maîtrise du noyau de leur produit, certains éditeurs mettent en place un dispositif d’extensions, qui permet d’apporter des enrichissements au produit, de manière propre et indépendante du noyau, en assurant la compatibilité avec les versions futures.

Les principes de cette séparation sont les suivants :

Le noyau doit être d’une grande robustesse, il est certifié par l’éditeur ; les contributions externes y sont rares.

L’interface entre le noyau et les extensions est bien documentée et stable, c’est à dire qu’un changement de version du noyau n’implique pas un changement de version des extensions.

L’éditeur stimule la réalisation d’extensions, car elles donnent de la valeur à son produit et témoignent aussi de l’existence d’une communauté, en soi une garantie de pérennité. L’éditeur offre en général une plateforme de mise à disposition des extensions. Il peut le cas échéant mettre en place un dispositif d’évaluation ou de certification des extensions.

Ce modèle noyau/extensions est celui qui réalise le meilleur point d’équilibre entre les rôles respectifs de l’éditeur et de la communauté, réunissant la garantie et l’engagement de l’éditeur, avec le dynamisme et le l’énorme capacité de développement de la communauté.

 

Je ne parlerai pas des forks en détail, qui est une scission dans un projet de développement, dans laquelle une nouvelle équipe de développement part de la même base logicielle pour faire évoluer le produit à sa manière. Les licences open source autorisent toutes les forks, c’est dans la définition même de l’open source. Il peut y avoir en gros deux raisons pour un fork : un désaccord quant aux orientations technologiques, ou bien un désaccord quant à la politique commerciale et de licences. Ainsi, si un éditeur prend une orientation qui déplait à la communauté, il s’expose à un fork. Par exemple le fork donnant naissance à Joomla en 2005, à partir de Mambo, un outil de gestion de contenus très populaire.

Selon les cas, le fork peut l’emporter ou bien vivoter, selon le dynamisme de la communauté. Il y a aussi des forks non pas communautaires mais d’entreprises commerciales, par exemple l’ERP OpenBravo, s’appuyant également sur Compiere comme socle de son développement.

 

Protection légale & Propriété Intellectuelle

Aux Etats-Unis en particulier, les éditeurs proposent, en association avec leurs offres de support, une protection légale vis à vis de possibles violations de brevets logiciels. Dans ce pays, une entreprise qui utiliserait des programmes violant des brevets pourrait se voire attaquer et réclamer des indemnisations potentiellement énormes si la compagnie est riche.

C’est devenu, ces dernières années, l’un des axes d’attaque les plus virulents des concurrents de l’open source, à commencer par Microsoft, qui a utilisé son accord avec Novell pour entretenir l’idée qu’il existe un risque à cet égard. Et paradoxalement, ces intimidations servent aussi les éditeurs open source commerciaux, qui vendent finalement de la protection légale autant que du support produit.

En Europe toutefois, les programmes informatiques sont explicitement exclus de la Convention sur le Brevet Européen, et d’une manière le recours au judiciaire est moins dans les mœurs, de sorte qu’il n’y a pas de crainte semblable.

 

La notion d'éditeur-intégrateur

Le marché informatique se divise depuis longtemps entre éditeurs et intégrateurs. Les éditeurs développent des produits, susceptibles de satisfaire un nombre important de clients. Les intégrateurs s’appuient sur ces produits pour construire des systèmes d’information répondant au besoin spécifique d’un de leurs clients.

De tout temps, open source ou pas, il s’est trouvé des prestataires tentés par le double jeu : éditeur et intégrateur à la fois, éditeur qui intègre lui-même son produit, intégrateur qui n’a qu’un seul produit à son catalogue. Et de tout temps, cela n’a pas marché. Parce que pour gagner des marchés, l’éditeur doit construire un réseau d’intégrateurs partenaires, et il ne peut y parvenir s’il est lui même le premier concurrent de ses propres intégrateurs.

Sur le marché des solutions open source, on rencontre fréquemment de tels éditeurs-intégrateurs, mais ils ne donnent jamais naissance à des solutions leaders. La tentation est grande, pour l’éditeur qui a du mal à trouver son business model, et du mal aussi à convaincre des prestataires d’utiliser son produit, de le faire lui-même. Mais le marché sanctionne toujours ces combinaisons.

 

Les prestataires

Pour les prestataires IT, intégrateurs de solutions open source, le business model est pratiquement inchangé, basé sur la vente de prestations et d’expertise autour des produits open source, ceci sous la forme :

de support,

de projets clés en main,

de prestations de conseil ou d’expertise en assistance technique.

Nous distinguons ici deux types d’activités, auxquelles correspondent des prestataires souvent différents : le support open source et l’intégration open source.

 

Les prestataires de support open source

Nous avons distingué ici distributeurs et prestataires, même si les distributeurs sont prestataires, à leur manière. Mais d’un point de vue historique, la frontière reste marquée. Les distributeurs n’offrent aucune autre prestation que la diffusion, le support et la formation, autour des logiciels inclus dans leur "distribution".

Mais il existe une telle diversité de composants open source, que le besoin est apparu très tôt d’avoir un support global, concentré entre les mains d’un prestataire unique. C’est sur ce métier qu’est né en France le concept de SSLL, Société de Service en Logiciel Libre : une société qui se propose d’assurer le déploiement et le support de configurations multi-produits à base de logiciels open source. Elles ont été rejointes plus tard par les SSII généralistes, ouvrant des centres de support open source.

 

Les prestataires de support open source peuvent également construire des applications spécifiques, mais leur cœur de métier est dans le support.

 

L’intégration de solutions open source

Les prestataires intégrateurs de solutions open source construisent des applications globales, des systèmes d’information, à base de logiciel open source. Bien sûr, ils assurent également le support de l’ensemble de leurs créations, incluant les développements et configurations spécifiques, et produits sous-jacents, mais leur cœur de métier est dans l’intégration, la construction d’applications.

La valeur ajoutée de l’intégrateur open source commence dans le choix de solutions. L’open source amène une immense profusion de solutions, dont certaines immatures, ou au contraire obsolètes. Cette richesse est aussi un handicap : beaucoup de clients craignent de faire un mauvais choix. L’intégrateur open source ne peut pas attendre que le Gartner ait sélectionné les heureux élus, il doit mener une action permanente de veille et d’évaluation, afin de déceler les produits prometteurs, et les produits les plus solides.

Au chapitre consacré au modèle de développement, nous verrons que l’open source a aussi beaucoup fait progresser le développement, et les prestataires intégrateurs sont les premiers à faire usage des bonnes pratiques, mais aussi des bons outils, issus de l’open source : IDE, gestion des sources, outils de tests et d’intégration continue, suivi des anomalies, etc. Les intégrateurs open source ont, en la matière, une longueur d’avance.

 

Prestation open source et prestation traditionnelle

Les produits open source communautaires n’ont pas d’éditeur susceptible d’apporter une aide commerciale ou marketing, un support à l’avant-vente, ou un support en phase de projet. Même pour les produits open source commerciaux, les éditeurs sont souvent de petites structures, aux ressources limitées, et plutôt tournées vers le développement produit.

Le prestataire prend donc souvent à sa charge une partie de l’investissement amont qui incombait traditionnellement à l’éditeur : il sélectionne les produits les plus solides et pérennes, en assure la promotion et la vente, voire une partie du support.

Devant l’extraordinaire montée en puissance des solutions open source, tous les prestataires IT espèrent une part du gâteau ; c’est ainsi que les grandes SSII généralistes ont fini par s’y intéresser. Mais elles ont beaucoup de difficulté à trahir les grands éditeurs traditionnels, ‘propriétaires’ avec lesquels elles vivent en symbiose depuis des années, dans une logique de licences-chères/prestations-chères. N’investissant pas en amont dans la veille technologique et la relation avec les communautés ou éditeurs open source, elles manquent de légitimité sur ces territoires nouveaux.

 

Synthèse

En guise de synthèse, nous analysons les relations entre ces différents acteurs de l’open source, en considérant trois types d’interactions, en forme de flux :

- Les prestations, y compris écriture de programmes, support, conseil, formation, intégration.

- Le code source, c’est à dire les logiciels.

- L’argent, enfin, qui fait de tout cela un business-model !

 

Les flux de prestations

Sur l'image suivante, nous représentons les flux de prestations intellectuelle entre les différents acteurs identifiés. Cette prestation peut être du développement de programme, ou bien de l’intégration, du conseil, du support, de la formation.

On distingue les principaux flux de service :

Contributions en prestations de développeurs salariés, de la part des distributeurs tels que Redhat, de donateurs tels que IBM ou Google, et dans une moindre mesure, d’éditeurs commerciaux et d’intégrateurs, au bénéfice des fondations tels que Apache qui ont en charge de grands projets open source.

Offre de prestations d’intégration, développement et support des intégrateurs et des éditeurs commerciaux, vers les clients et utilisateurs finaux.

 

Les flux de code source

Sur l'image suivante, nous avons fait apparaître les flux de code source. Pour le distinguer de la prestation de développement, qui relevait des flux précédents, on ne considère ici que la livraison de programmes déjà écrits.

Ici, les principaux flux sont :

Le code source constituant les grands logiciels open source, diffusés par les fondations et utilisés par les éditeurs commerciaux, et par les intégrateurs.

Les programmes distribués par les distributeurs, à destination des clients finaux.

Les programmes des éditeurs commerciaux, à destination des clients.

 

Les flux d’argent

Enfin, cette dernière image représente les flux d’argent entre ces différents acteurs.

On y distingue les principaux flux suivants :

Le paiement par les clients finaux des prestations de support aux éditeurs commerciaux et aux distributeurs.

Le paiement par les clients finaux des prestations d’intégration et de support aux intégrateurs.

 

On pourrait discuter aussi de modèle de développement, mais ce serait partir sur un autre débat.

 

La suite (responsabilité des développeurs) dans le prochain post.

[Dev On Web]

OMG les pavés oO

[Paul MONFILS]

[Paul MONFILS]

Responsabilité des développeurs:

Vous êtes entièrement responsable de votre travail, payant ou gratuit. Vous allez avec des exemples comprendre l'utilité d'avoir une bon RC pro ou un bon conseil juridique.

je donne des exemples de cas:

- Je considère cet exemple large afin de répondre d'une pierre deux coups à une question posée aussi en MP par un membre: un concepteur de site (qui fait donc du développement). Vous êtes porteur de projet e-commerce et décidez de confier la mission à un prestataire extérieur. Si aucun contrat de prestation ne stipule la cession intégrale des droits de propriété intellectuelle attachés au site, c'est le prestataire qui en est propriétaire. Sans contrat, si vous changez d'hébergement, la justice française considère que l’hébergement du site par un nouveau prestataire suppose une reproduction et qu’en l’occurrence, celle-ci constitue un acte de contrefaçon : « en faisant reproduire l’œuvre [du prestataire] sans son accord [le client] a commis à l’encontre [du prestataire] un acte de contrefaçon ». (TGI Paris 10-11-11). Cet exemple illustre parfaitement la nécessité pour les sociétés qui font appel à des prestataires extérieurs pour réaliser leur site internet de bien prévoir dans le contrat la cession intégrale des droits de propriété intellectuelle attachés au site.

 

 

- Autre exemple (pour répondre aussi à un autre membre du coup): une société, dont l’activité est la vente de produits que je ne citerai, a conclu un contrat pour la fourniture d’un système informatique de gestion (licences, intégration et maintenance). En l’absence de solution exploitable un an après la date de livraison prévue, le client a résilié le contrat, obtenu le remboursement, par le fournisseur, des factures payées, et mis en demeure ce dernier de lui verser en outre 410 604 € de dommages et intérêts.

Face au refus du prestataire de l’indemniser, le client a saisi le Tribunal de commerce pour obtenir des dommages intérêts dont une somme importante de coûts de personnel interne. Le temps de travail comptabilisé correspond au temps consacré à la mise en œuvre du projet (participation à la définition des besoins, au développement des interfaces, au paramétrage, et aux tests et aux formations) et à pallier l’absence de solution informatique.

Après avoir jugé la résiliation justifiée, le Tribunal a fixé les dommages et intérêts dus au client à plus de 200 000 € (T. COM. 2-6-09). Le prestataire informatique a fait appel de cette décision et le client formule les mêmes demandes de réparation en appel. La Cour d’appel confirme la décision sur la responsabilité du fournisseur qui n’a pas été en mesure de fournir la solution commandée (CA 3e CH. 19-1-11). Elle confirme également la réparation des coûts salariaux internes, augmentant l’indemnisation à ce titre compte tenu de nouveaux justificatifs produits par la victime (justificatifs de la rémunération moyenne des salariés concernés).

 

- Exemple répondant à la notion de module facturé et ne répondant pas intégralement à la fonctionnalité requise par le client. Un arrêt de la Chambre commerciale de la Cour de cassation du 11-12-07 approuve une cour d’appel qui a condamné un prestataire à verser des dommages et intérêts pour avoir livré un script ne couvrant pas une des fonctionnalités requises par le client. L’expert judiciaire désigné en première instance a estimé que la solution livrée comportait une anomalie et que le défaut était imputable au concepteur et non à la société cliente.

L‘obligation de délivrance dans les contrats est satisfaite par la livraison d’un bien ou d’une prestation conforme à l’objet du contrat et dans les délais prévus (lorsque donc il y a contrat). Dans le domaine informatique, la conformité s’apprécie au regard de la commande et aussi de manière complémentaire, au regard de l’usage.

 

Dans le cadre du gratuit, tout travail délivré gratuitement est à vos risques et périls si je m'autorise à parler ainsi. Dans le cas ici présent de modules "offerts", les mises en cause sont aussi variées. Je donne ci-dessous des exemples de situations rencontrées ici ou ailleurs (Presta ou d'autres solutions) qui sont valables pour les modules payants ou gratuits mais aussi dans le cadre d'autres prestations:

- défaut de fonctionnement ou de performance.

- insuffisance de préconisations ou d'informations.

- erreur de conception.

- dans le cas de travail sous contrat: non-respect du cahier des charges, retard de livraison...

- dans le cadre de formations sur des solutions e-commerce: erreur, omission, insuffisance de formation, violation des droits d'auteur...

- dans le cadre d'installations: erreur d'appréciation, omission, perte de données...

 

- dans le cadre de maintenance : omission, négligence, malveillance, dommages aux biens confiés...

- dans le cadre de migration d'hébergement: perte ou détérioration de données, divulgation d'informations confidentielles ou violation de la propriété intellectuelle...

 

Vous l'aurez compris, sans RC Pro adéquate ou sans conseil juridique, que le travail soit gratuit ou payant, et qu'un client aie envie de s'en prendre à vous dans des exemples comme ceux donnés précédemment: aïe, aïe.

[RUNps]

@Paul MONFILS

Syntèse, fort intéressante.

Je dis merci même si elle m'est pas particulièrement destinée.

 

 

Ce que j'ai remarqué, c'est que les réponses données suite à mon intervention étaient :

libre n'est pas gratuit, libre n'est pas gratuit, et pour changer un peu : libre n'est pas gratuit ???

C'est des coups à attrapper les mouches à force de bailler.

 

Pourtant, c'était pas faute de l'avoir dit (je me cite, dès mon 1er post) :

Ok, l'Open Source n'est pas équivalent à gratuité au même titre que l'Open Source n'est pas équivalent à une oeuvre de charité.

 

 

Encore une fois, je m'insurges contre ce genre d'idées qui était à l'origine de mes interventions :

il est évident que le domaine de l'e-commerce, open source, gratuit ou pas, brasse de l'argent. C'est un domaine, qui contrairement à l'éditorial par exemple (avec joomla, drupal, typo3, etc.), ne vise que le profit pour ses utilisateurs.

Parce que le Soft que l'on créerait gènèrait des profits à ceux qui les utilisent serait alors la raison pour laquelle on ferait payer les utilisateurs ?

 

Ce serait cela les idées de l'Open Source ???

 

Désolé, je trouve cela scandaleux de lire ce genre d'idées.

Et ce n'est en postant un bouquin entier sur l'Open Source qui me fera changer d'avis sur ce point.

 

 

Vous savez très bien sinon plus que moi que les Joomla, Drupal, Typo3 (qui soit disant seraient contraire au secteur du e-commerce) sont exploités par bon nombre d'entreprises et elles font des profits grâce à eux, directement ou indirectement.

Ce n'est pas pour autant que tout ce qui tourne autour de ces Soft soient payant.

C'est faux.

Pour Drupal par exemple la gratuité fait partie des objectifs qu'ils se donnent, quelque soit les modules, y compris la vente en ligne.

 

 

Maintenant, je sais que le sujet est loin d'être populaire.

Mais apparemment ça à l'air de convenir à la majorité que sortir le carnet sans même se poser plus de questions.

Il y a du travail dérrière, beaucoup même, alors c'est normal : payons.

 

Bravo !!!

 

La dessus, je vous laisse faire vos compte.

[Raphaël Malié]

Bonsoir,

sachant que j'ai passé toute ma vie étudiante à travailler le soir et le WE gratuitement sur des logiciels Open Source que j'ai créé ou sur lesquels j'ai participé, sans gagner un seul centime, je crois avoir une bonne idée de ce qu'est l'Open Source merci. Vous avez éludé deux fois mes questions, donc visiblement vous n'avez jamais travaillé dans ce domaine ... que pourtant vous semblez maîtriser bien mieux que nous tous ici

Je n'ai jamais dit que logiciel e-commerce = faire payer les utilisateurs. J'ai simplement dit que l'e-commerce brasse de l'argent, et n'est là que pour ça, et qu'il est donc largement moins choquant de voir des modules payants. Bien sur que les CMS brassent aussi de l'argent, mais une énorme partie des sites webs ne sont pas à but lucratif ou promotionnels. C'est pourtant pas très compliqué à comprendre.

 

Maintenant si vous avez le secret pour arriver à financer plus de 100 employés, des locaux à Paris pour les accueillir, et tout le matériel qui va avec, sans vendre un seul module, je vous suggère fortement d'écrire à notre direction afin de leur proposer votre modèle économique magique, ils sont parfaitement ouvert à la discussion.

 

Je vous rappel pour une énième fois que PrestaShop est gratuit et libre, et que vous pouvez monter un site e-commerce sans débourser un centime.

 

Cordialement

[Julien Breux]

En effet, encore une fois, ne pas mélanger PrestaShop solution et PrestaShop SA.

 

Cordialement

[Atch]

En effet, encore une fois, ne pas mélanger PrestaShop solution et PrestaShop SA.

 

Cordialement

 

Salut Julien,

 

 

Hmmmm je ne sais pas qui mélange le plus

 

En installant Prestashop "solution", on se retrouve avec du Prestashop SA (PUBS Addons) dés l'installation et ensuite Partout dans la solution (Modules Partenaires Prestashop SA, Liens Addons, News Addons, etc...)

 

Meme la NL de Prestashop Solution c'est du Prestashop SA...

 

Pas évident de ne pas mélanger du coup pour les utilisateurs, on a plus l'impression que ça ne fait qu'un !

 

V++

 

Atch

[Paul MONFILS]

C'est effectivement un ressenti partagé Atch, il est difficile de distinguer PS Solution de PS SA.

[Julien Breux]

Je suis conscient de ceci.

 

J'en prends naturellement et personnellement bonne note.

[shagshag]

Bonjour,

@RUNps : 2 choses

 

1/

il ne faut pas comparer la communauté de PS avec celle de Joomla, Drupal, Typo3.

 

Prestashop est utilisable dès l'installation, quoi que certains en disent. Si on prend Prestabox ou OVH ils proposent l'installation en un clic. Donc pas besoin d'être un geek pour l'installer ni pour l'utiliser. La communauté PS a donc plus d'utilisateurs finaux (commercants) que d'intermédiaires (développeurs, geek...).

 

Joomla, Drupal, Typo3 n'ont pas la même cible. Installe Typo3 et essaye de faire qqch tu comprendras. La communauté se trouve donc inversée, plus de développeurs que d'utilisateurs finaux. ces derniers traitants en priorité avec des intermédiaires (les développeurs).

 

Donc si qq'un de la communauté Joomla a besoin d'une fonctionnalité soit il sait le faire et il le fait soit il demande et presque tous les autres le savent et si l'idée est bonne l'utiliser à leur profit. S'il décide de proposer ce qu'il a fait en payant, 100 personnes sont prêtent à faire pareil en moins chère. De plus il ne le fait pas pour lui mais pour un client donc le développement est déjà rentabilisé.

 

A contrario si un commerçant veut un carrousel3D sur son PS bin il sait pas faire c'est pas son métier alors il demande. Là il tombe soit sur des utilisateurs finaux qui savent pas non plus soit sur des développeurs qui ne vont le faire que pour le profit (ils n'ont pas de boutique donc au final il n'en ont pas besoin de ton carrousel) Donc ils proposent ça en payant logique.

 

Sachant qu'un développement sous PS sera payant il y a trois solutions :

- le développeur fait payer plein pot le commerçant et la solution n'est pas diffusée.

 

- le développeur fait payer pas cher le commerçant et revend la solution en tant que module +/- au même prix.

 

- le développeur fait payer plein pot le commerçant et redistribue la solution en tant que module gratuit ou presque.

 

la 1ère solution n'entre pas dans ce débat et (désolé mais c'est vrai) les commerçants qui demandent sur le forum sont venu ici appâté par le gratuit et sont radins .

La 3ème n'est pas envisageable non plus, elle fonctionnerai sur WP, Joomla ou un truc non lucratif. PS est pour gagner de l'argent, les modules sont pour se démarquer et gagner plus. Donc si les concurrents peuvent avoir gratuitement ce que j'ai payé plein pot bin non.

 

Donc il reste quoi : un module diffusé sur addons en payant.

 

 

2/

 

Il ne faut pas confondre Prestashop, Prestashop S.A. et les contributeurs de Prestashop qui développent des modules et des thèmes.

 

Prestashop est gratuite et Open-source :

 

 

Prestashop suit l’évolution classique des solutions Open Source : création d'une application, déploiement, levée de fonds. Un business model qui repose sur le succès d'une application, et non sur le profit généré. De plus elle est sponsorisée par des sociétés avec les modules Paypal, ebay... les pubs sur les hébergements... c'est ce qui lui permet d'être gratuit.

 

Une société ne fait pas de l'Open Source par grandeur d'âme, elle doit gagner de l'argent sinon elle meurt. Ensuite les employés, dirigeants peuvent avoir des convictions, un idéal et c'est encore mieux.

 

De plus en PHP le choix de l'Open Source est presque obligatoire, c'est du langage interprété donc les sources sont toujours disponible. Donc licence ou pas, rien n’empêche de le copier s'en inspirer pour faire une solution concurrente.

 

Enfin Prestashop est à l'origine un projet d'étudiants cela peut expliquer un peu plus ce choix de licence (idéal d'étudiant, imposé par les profs...)

 

D'un autre côté il y a les contributeurs comme moi et d'autres, petites sociétés sans mécènes derrière qui doivent bien faire des profits aussi. Ils font de l'OpenSource s'ils le veulent mais pas du gratuit parce qu'il faut manger et comme je l'ai dit la communauté des utilisateurs finaux est venue ici pour le gratuit donc faut pas compter sur les dons.

De plus le gratuit à un coup pour le développeur comme ça a été dit plein de fois. Crontab for PrestaShop téléchargé 7999 fois. Chaque semaine j'ai au moins 10 demandes de support. ça prend du temps donc de l'argent. Donc un module sérieux gratuit coûte de l'argent à un développeur. Vous pouvez dire que ça apporte des contacts et des clients potentiels. NON je suis sur PS depuis 2007 les modules gratuits j'en ai fait plein ça m'a apporté UN client (valable).

D'ailleurs tu peux noter : 7999 téléchargement => 3 votes. Youpi ! ça donne envie

 

Enfin il y a Prestashop S.A. qui fait aussi des modules au même titre que les autres contributeurs.

[daniel3000]

Bonjour,

 

merci à Paul MONFILS pour ce travail.

Il montre de manière objective le cadre dans lequel on s'inscrit lorsqu'on utilise de l'open source.

C'est sans aucun doute une base, et si l'on choisit l'open source, cette base sera dans tous les cas à respecter.(Personellement j'avoue que je dois le relire).

 

Le commentaire de shagshag montre bien que, ensuite, tout est question d'appréciation (financière, éthique....), et que c'est dans cette appréciation que ce situe "l’âme" d'une communauté.

Son point 2/ est très clair, honnête et pas contestable sur sa logique (un développeur doit se rémunérer).

Le point /1 est incomplet, en limitant à 3 solutions: il confronte uniquement développeur et commerçant. Il y manquerait me semble-t-il un cas de figure n°4, qui doit quand même bien se produire:

- Le développeur est plus compétitif dans son travail car il s'appuie sur certains modules gratuits ou peu onéreux déjà développés par certains de ses collègues. Il décide éventuellement à son tour de faire bénéficier la communauté prestashop d'une partie de son propre travail.

 

n'est-ce pas aussi là une illustration de la notion de communauté? Le but des modules gratuits ou accessibles n'est-il pas de maintenir la solution Prestashop toujours au dessus autres solutions?

[shagshag]

Bonsoir,

 

le cas de figure 4 que tu dis est un peu différent. Ceux sont des modules ou autres solutions que des développeurs mettent à disposition de la communauté pour aider au développement.

Ce genre de choses ne se retrouvera pas sur addons (ce n'est pas le but de cette plateforme), sera même rarement des modules complets, juste des bouts de code et surtout ça n’intéressent pas les commerçants.

Mais rassure toi il y en a plein, des très complètes, pratiques, futures, spécifiques... faut pas croire on aime bien aider et partager notre expérience (parfois on se retrouve et on se partage un bisounours grillé en buvant du jus de licorne fermenté)

 

Si on veut il y a une sous communauté de développeurs dans celle des utilisateurs de PS, elle évolue sur le forum et ailleurs.

[chantane]

Paul, Merci pour votre contribution.