La tentation de vendre son code


Beaucoup d'indépendants ou de petites sociétés de service réalisent des développements sur des projets Open Source et les mettent ensuite en vente pour en tirer un revenu. Attention, ceci ne marche qu'un temps...

Diffuser un module pour le vendre, module réalisé en Open Source (parce que utilisant des briques Open Source sous licence obligeant à etre alors soi même Open Source), c'est aussi courrir le risque de voir son module copié et revendu moins cher. On serait alors amené à penser que ce "copieur" concurrence le projet source (le projet ou module d'origine qui a été forké). Se pose alors une question de savoir comment permettre à l'auteur original de conserver les retombées financières de son module ?

C'est une mauvaise question. Car le problème n'est pas là. Le problème est de vouloir baser un business modèle en vendant du code. Ceci n'est pas un business modèle viable dans l'Open source. C'est permis, encouragé si vous le pouvez, mais cela n'a jamais marché sur le long terme.
On ne peut pas vendre du code en Open Source, même si c'est ce que font certains sur certaines places de marché en pensant que cela durera. Par définition, le code peut être recopié, revendu ou même donné en toute légalité en direct ou sur une autre place de marché, au grand bonheur des utilisateurs. Et c'est le souhait du modèle Open Source même.

Vouloir dire qu'il faut "stopper" cela, c'est vouloir "vivre" en vendant du code. Il faut vendre... autrechose.
Les auteurs ne sont pas "protégés" par la place de marché ? Une place de marché sur des composants Open Source n'a absolument pas vocation à "protéger" les auteurs. Au contraire, elle doit servir à populariser et donc rendre visible le plus possible les modules ou oeuvres dérivées, favorisant ainsi leur diffusion (par copie, et accessoirement par d'autres achats).
Cela favorise ainsi la popularité créant une augmentation de demande qui pourra ensuite etre monayé, mais selon une autre forme que la "vente directe de code".
C'est par cette philosophie (la vrai philosophie Open Source) que les projets Open Source majeurs ont atteint des sommets.

Bref, pour lutter contre cette "concurrence" qui n'est pas si malsaine que cela, la place de marché doit donc jouer sur la visibilité, et la marque du projet ayant tous les droits dessus. C'est avec cela qu'elle pourra réduire la visibilité d'une place concurrente "doublon", rendant l'initiative peu productive et obligeant alors le "concurrent" à jouer le jeu "Open Source partenaire" (sous-entendu, je rentre dans les rangs du projet officiel) à fond plutôt que le jeu de l' "Open source doublon".
Car vouloir bloquer un module ou un soumission sur une place de marché Open Source pour cause de doublon est difficile: Le problème est comment faire la limite entre copie 100% et copie juste à 90% avec 10% d'ajouts qui justifie la plus-value apporté par le doublon (qui n'est ait plus un du fait de ses 10% d'améliorations) ? Et si on pouvait mesurer ce seuil, quel devrait être le pourcentage qui définit la limite autorisée (50%, 80% 90%). D'un point de vue "pratique", je pense qu'il est très difficile de jouer la dessus (et d'un point de vue juridique, cela pourrait meme être illégal de filtrer sur la base de "tu as copié" alors que la licence Open Source est faite pour cela. Cela peut même se retourner contre la plateforme pour cause de concurence déloyale, les critères d'acceptation devant être les même pour tout le monde et ne pouvant se baser sur le code. Bloquer un module sur une place de marché Open Source soumis par X plutôt que Y sur la base du code commun, c'est faire du favoritisme de manière illégale (puisque le code étant identique, les critères sont forcément parreillement acceptés). Il faut donc d'autres leviers, jouant sur des critères de visibilité, du genre, on priorise ou on met en avant les "Preferred partner", ou encore les modules donc l'accès aux sources est accessible publiquement et non seulement fourni lors de l'achat (ce qui est tout à fait possible avec la plupart des licences libres), ou encore l'age du module, la date de soumission, ... C'est pas simple mais attendez vous, si une place de marché de composant Open Source a peu de doublons, à ce que ce genre de cas se multiplient, même si dans certains cas, cela ne semble pas souhaitable, c'est bon signe pour le projet (Savez-vous combien de distribution dérivées de Debian ou Ubuntu existent ? Dès lors que sur le plan visibilité, on sait que cela est un "fork de", même si c'est à 99.9% le même code, le produit ou projet initial y trouve son compte... à condition que le business modèle du projet initial ne soit pas sur la vente de code.
Si un projet ou un module plait se développe, il existera un jour, accessible à tous, une version équivalente accessible gratuitement, il faut s'y préparer, c'est la raçon du succès. Alors autant le laisser au plus bas prix d'entrée et chercher une autre source de revenu que la vente de son code.


Que dire alors à ceux qui diront "Oui mais les "copieurs" ne respectent pas ou tuent la communauté ?


Oui, obenir le respect des partenaires d'un projet Open Source est important, mais justement, ce n'est pas en allant contre le phénomène Open source qu'on respecte cela. Le problème est "à la source", à savoir: Croire qu'on doit pouvoir vivre en vendant du code en Open Source. On peut être éditeur et bien en vivre, mais pas en vendant du source sous licence libre.
Il faut oublier cette idée un fois pour toute. Cela fait des années que je met en garde, et plus un projet grandit, plus ce sera vrai !!
Sauf si on veut que le projet ne se développe plus, ce phénomène est une conséquence d'un projet qui réussi. As-ton vu Canonical essayer de faire fermer les sites dédiés à une distribution copiée ou basée sur Ubuntu ? Et les grands gagnant de ces tonnes de copies ou fork... c'est Canonical... Et il est clair que Canonical a bien compris qu'essayer de vivre en faisant payer le code libre de sa distribution n'était pas un bon modèle économique, mais qu'il fallait moneyer autre chose. Nous, les développeurs Open source, il nous faut comprendre cela également ! Une place de marché peut servir de complément financier, c'est bien, mais si le projet continue de se populariser (et c'est un souhait en général), ce complément va disparaitre.
Aucun projet Open Source ne peut protéger directement les rémunérations des "auteurs d'oeuvres dérivées" (aucun ne le fait d'ailleurs, hormis par le levier de la visibilité "module partenaire", "module choix de la rédaction", "module qualifié par l'éditeur", ...) surtout quand le projet est devenu populaire. On peut certes réver et se dire qu'on arrivera à faire ce qu'aucun projet n'a su faire avant nous, mais c'est désservir le projet sur le long terme.
C'est un point de vue personnel, bien sur, et je comprend l'autre point de vue, celui de ceux que j'appelerais les libristes "à demi", autrement dit les libristes qui veulent bénéficier des avantages du libre sans ses inconvénients (car cela peut être frustrant, mais avec un bon recul, surtout temporel, on se rend compte que c'est un mal pour un bien et on finit par ne plus être frustré d'être copié, mais satisfait: le projet se développe, il va donc être possible de gagner sa vie... autrement que par la vente de code...).