Blog

Open-source, ce n’est pas (forcément) gratuit

Aujourd’hui on peut lire parfois « Les solutions open-source vous mentent, elles ne sont pas gratuites ». C’est amusant dans certains cas, mais moins lorsque ce sont des conseils adressés aux professionnels pour les envoyer vers des solutions propriétaires bien payantes.

Pour le commun des mortels, l’open-source c’est Firefox et OpenOffice LibreOffice qu’ils utilisent, et Linux « le symbole ». Admettons qu’à ce stade il y ait confusion…

Mais quand on est dans l’informatique, quand même ! J’ai pensé avoir un peu de matière pour éclairer les personnes intéressées, et corriger les inexactitudes qui ternissent un si bel élan mondial (souvent) de partage et d’amélioration collective.

Définition de l’open-source

« Open source » désigne un logiciel dans lequel le code source est à la disposition du grand public, et c’est généralement un effort de collaboration où les programmeurs améliorent ensemble le code source et partagent les changements au sein de la communauté ainsi que d’autres membres peuvent contribuer.

WIKIPEDIA

On parle ici d’accès au code source, c’est à dire le « texte informatique » qui, une fois compilé ou interprété, permet de faire fonctionner le logiciel. Si vous savez comment compiler ou interpréter un programme, vous pouvez en effet l’utiliser gratuitement. Mais vous pourrez surtout comprendre comment il fonctionne (à des fins de formation, de correction ou de sécurité par exemple) et le modifier; pour votre usage unique, ou bien autant que faire ce peu, pour le proposer au reste de la communauté de ce produit. Là aussi, gratuit, paf !

Pourquoi donner accès à son propre travail ? Comment en tire-t-on des revenus ?

Faut pas être fou pour filer gratos le fruit de son dur labeur à n’importe qui ? Pas vraiment, c’est plutôt un bon calcul, et sur plusieurs points. Exemples :

  • Une TPE donne à la communauté son travail qui constitue les bases d’un nouveau programme révolutionnaire. Si le projet plaît, plusieurs personnes vont venir se greffer dessus et compléter ce travail. La TPE dispose donc, de manière totalement imprévisible certes mais néanmoins gratuite, d’une force humaine décuplée. Ces « contributeurs » vont non seulement prendre en charge une partie du développement, mais aussi (souvent) faire la promotion de ce programme dans leur propre communauté. Le projet gagne donc également en visibilité.
  • Cette même TPE reste la créatrice du programme et est maintenant le chef d’orchestre de son développement. Elle est donc l’interlocutrice privilégiée pour tout prospect souhaitant utiliser ce programme, voire y rajouter des fonctionnalités spécifiques. Et ça ce sont des prestations payantes : audit, installation, configuration, formation sont toujours à prévoir, pour un produit open-source ou propriétaire.

Et les contributeurs professionnels ?

Ce sont à peu près les mêmes logiques qui vont motiver une entreprise à contribuer à un projet. Elle va pouvoir légitimer commercialement ses compétences sur le produit, puisqu’elle participe à son évolution, et pouvoir utiliser le produit comme point de départ pour ses propres besoins, en pouvant compter sur la communauté pour continuer à le faire évoluer et à le sécuriser.

Une étude montre que 80% des contributions du noyau linux sont faites par des gens qui sont rémunérés pour cela. C’est donc bien un business model que de construire ensemble une plateforme qui fonctionne permettant ensuite d’y rajouter des services ou des composants vendus par sa société.

Et les contributeurs particuliers ?

Le contributeur « non-professionnel », qu’on va définir comme « passionné », n’a généralement pas de vision pécuniaire lorsqu’il rejoint un projet. Il adhère à ce que le produit permet de faire, ou le trouve « trop puissant » techniquement, bref ça lui plaît et puis c’est tout. Selon son implication, il va pouvoir devenir un expert de ce produit, voire du langage qui est utilisé pour coder ce produit, et de fait séduire des employeurs potentiels pour l’une de ces raisons. Comme les projets open-source sont généralement publiés sur des plateformes publiques (Gitub, Bitbucket, etc…) tout le monde peut consulter qui y contribue, dans quelle proportion, voir spécifiquement le travail d’un-tel, bref y trouver bien mieux qu’un CV : du concret !

Pour aller plus loin, regardez la conférence qui parle d’elle-même d’Antony Ricaud à Sud Web 2012 :

Faire partie d’un projet, ça veut dire (savoir) coder ?

NON, il y a beaucoup d’autres besoins sur un projet open-source : tests (!), traduction, documentation sont des besoins très pertinents voire vitaux et il est dommage d’utiliser les compétences d’un développeurs à ces tâches plus accessibles par le commun des mortels. Donc si ça vous démange, même sur les projets les plus gros, lancez-vous ! Vous serez très bien accueilli, c’est certain !

Pourquoi ça coûte des sous d’utiliser une solution open-source, alors ?

Comme on l’a vu plus haut, rares sont les programmes qui ne nécessitent aucune intervention spécialisée pour les utiliser, même si ce sont souvent les plus connus. Dans l’univers professionnel, on est souvent face à des solutions complexes, nécessitant beaucoup de configuration, de la formation voire des adaptations spécifiques (qui sont possibles puisque le code source est accessible). Chaque projet demandera donc l’intervention d’un professionnel qualifié, donc des frais. Et c’est tout ! Pas de licence. Car sur les solutions propriétaires, vous payez aussi tout ça, plus une licence. Elle est uniquement là, la différence !

Si vous avez toutes les compétences requises, une solution open source ne vous coûtera pas un sous (voir cas particuliers sur les licences et bien entendu les frais de fonctionnement sont à prévoir). Maintenant est-ce qu’un E-commerçant sait généralement développer en PHP/SQL/Javascript/HTML/CSS, utiliser Photoshop, faire son référencement et administrer un serveur web ? Non, chacun son métier, il a déjà beaucoup à faire.

Les solutions open-source mettent à disposition gratuitement une base de travail qui parfois peut suffire ou parfois doit être complétée pour des cas spécifiques. Un moteur E-commerce international ne peut évidemment pas fournir toutes les liaisons avec tous les transporteurs et toutes les banques de la planète. Ce n’est pas son rôle. Il faut alors compléter le projet avec le travail de groupes plus réduits qui parfois donnent également ce savoir et parfois le vendent. La plupart du temps, le prix est dérisoire comparé au coût de développement de la même fonctionnalité, c’est donc intéressant si le travail est de qualité et qu’il répond aux besoins.

Finalement, l’utilisateur d’une solution open-source devra souvent faire appel à des compétences externes pour la paramétrer et la compléter au besoin. J’ai du mal à voir où est le scandale dans l’histoire, et vous ? A part à laisser croire que tout est vraiment gratuit comme le font certains…

En tant qu’utilisateur (ou client), quels intérêts apportent une solution open-source ?

Aucune société ne peut comparer ses compétences humaines à une foule de passionnés bénévoles, pas même Microsoft face à la communauté Linux. D’un côté des employés (qui peuvent être passionnés) qui suivent des instructions dictées par une logique commerciale, de l’autre des gens qui donnent de leur temps pour que le produit fonctionne et évolue du mieux possible.

Un produit open-source n’a aucune garantie de mieux fonctionner qu’un produit soumis à licence payante, ou d’avoir moins de bugs. Cependant, ce qui fait la principale qualité d’un produit open-source, c’est la taille et/ou l’activité de sa communauté. Si celle-ci est dynamique, c’est l’assurance d’avoir un produit fréquemment mis à jour et qui sera mieux sécurisé. A l’inverse, une communauté pauvre est très risquée pour les raisons inverses. Comme toute « entreprise » (humaine), une communauté peut avoir ses années de gloire et dépérir dans la foulée.

Et donc quels sont les inconvénients d’une solution propriétaire ?

Je vais répondre sous la forme de deux histoire complètement fictives mais réalistes. Toute ressemblance avec des cas concrets est volontaire.

La société TRUC lance en 2000 une gamme de gestions commerciales moderne et novatrice. Ses prix de lancements sont volontairement faibles : elle doit bien se faire une place sur le marché. Les années passent et la mayonnaise a pris : elle compte plusieurs milliers de clients avec tout un petit réseau de revendeurs. En 2005, elle doit gérer sa croissance, s’implanter dans de nouveaux pays, rémunérer ses apporteurs d’affaire : elle augmente ses tarifs. Les prix sont toujours intéressants et elle continue sa croissance, jusqu’aux sommets. En 2010, elle est bien implantée, avec toute une gamme de produits. Elle relève ses prix de vente et de maintenance pour s’aligner au marché. Elle est devenue une référence et est poussée par des intégrateurs qui sont rémunérés sur leurs ventes. Les clients sont captifs d’une solution « qui fonctionne » et qui serait trop complexe à migrer, et paient chaque année des frais de maintenance exorbitants qui valent 80% du prix d’achat du logiciel, lequel n’évolue plus vraiment que tous les cinq ans.

La société MACHIN implantée en Aveyron, qui compte un seul homme à bord : son gérant Mr DUPOND, propose en 2000 une petite solution de gestion commerciale qu’il a développé lui-même suite à deux demandes dans son entourage. Le produit n’est pas très cher et très bien fait avec des spécificités intéressantes. Avec un peu de démarchage, il séduit quelques PME locales. Quelques années plus tard, la société emploie 2 personnes et compte une cinquantaine de clients très locaux. Mais Mr DUPOND approche de l’âge de la retraite et n’a plus envie de continuer à développer. Ses 2 employés assurent le support et ça va bien comme ça : il gagne bien sa vie, c’est très bien. Il faudrait revendre, mais qui code encore en OUECHDEV en 2014 ? Il faudrait tout recoder, la dette technique et fonctionnelle accumulée par le projet est faramineuse ! Mieux vaut ne surtout rien bouger. Le temps passe et le produit de la société MACHIN n’évolue plus du tout, assurant le service minimal, certes avec du service et un prix correct. Pendant ce temps la législation change, les usages informatiques passent aux mobiles, le matériel informatique évolue, mais 50 PME Aveyronnaises restent figées dans les années 2000 pour leur gestion commerciale et comptable.

En conclusion, le produit propriétaire d’une grande entreprise et ses services se paient toujours au prix fort. Vous ne serez toujours qu’un petit client dans sa nasse sans aucune écoute pour vos cas particuliers, mais la pérennité de votre produit est assurée. Le produit propriétaire d’une petite société peut être intéressant, tant qu’elle continue de le faire évoluer, et surtout d’exister ! Vous êtes dans tous les cas prisonniers de leur propres envies fonctionnelles et de leurs tarifs sur le monopole qu’ils se sont créé.

Gardons à l’esprit un fait déterminant : aucune solution n’est éternelle, surtout en informatique ! Que votre outil soit open-source ou propriétaire, vous devrez le faire évoluer régulièrement ou le changer tous les 3 à 5 ans minimum, sous peine de prendre la poussière : ne rien faire vous coûtera plus cher que de changer de solution, c’est certain ! C’est donc l’occasion de revoir l’état de la concurrence dans les 2 mondes : propriétaires et open-source.

Précisions

Tout ce qui n’est pas open-source n’est pas pourri ! Je tiens juste à expliquer les valeurs et les enjeux de l’open-source, avec forcément comme comparaison le monde propriétaire qui n’est forcément pas ici sous son meilleur jour. Je dois avouer que j’utilise Windows…(mais je ne code pas !) Malgré les efforts de la communauté, tous les usages ne sont pas couverts aussi bien que par certaines solutions propriétaires. Photoshop est par exemple indétrônable dans la retouche photo.

Le monde de l’open-source est régit par des licences qui définissent les droits concrètement accordés quant à l’utilisation faite du code mis à disposition. Il est important de s’y référer avant de publier ou utiliser un tel projet. On ne peut généralement pas récupérer un projet open-source pour le revendre avec licence en suivant, même en ayant modifié quelques lignes de code (heureusement !).

2 Comments

  1. MiniMousse

    J’ai apprécié cet article qui attire l’attention sur des points importants des logiciels open-sources.

    J’ajouterai un exemple de mode développement Open-Source qui a attiré bien des contributeurs : Docker.
    Le premier contributeur n’est plus la boite à l’origine de Docker, mais … RedHat. Qui a bien compris l’intérêt de la solution dans une stratégie Cloud et son axe de développement d’activité de services (hébergement, support)

    Un autre aspect qu’il ne faut pas négliger, c’est la question des licences. Il existe un nombre significatif d’open source gratuit pour un usage personnel, mais payant dans un usage professionnel.
    Voire, qui impose la publication des sources de l’intégralité de l’application utilisant une librairie open-source. Ce qui peut être désastreux dans un contexte commercial.
    Un exemple : la librairie « iText PDF », qui est publiée sur SourceForge, mais qui a un mode de licence piégeant. C’est une librairie énormément utilisée, mais quasiment toujours en infraction !

    Et la question de l’utilisation d’un open-source pour un logiciel critique doit être exposée et réfléchie attentivement.

    Exemple : j’utilise une librairie open-source vitale en terme de sécurité, mais dont le développement n’inclut qu’un développer employé à temps complet (ie : OpenSSL). Est-ce que ce scénario est raisonable ?

    La catastrophe OpenSSL aura coûté des dizaines de millions aux entreprises.

    Même question pour TrueCrypt. Si c’est pour éviter qu’un voleur ne récupère pas mes données personnelles les plus sensibles en volant mon portable, c’est probablement OK de l’utiliser.
    Maintenant, si je dois protéger les données de santé de milliers de mes clients, alors je n’ai probablement pas le droit de prendre le risque.
    TrueCrypt n’avait simplement pas un support de développement suffisant pour un logiciel aussi sensible.

    J’ai bien aimé la comparaison entre la grosse société (TRUC) qui, établie sur le marché, se gave en maintenance vs la PME (MACHIN) de 3 personnes.
    Si le logiciel est critique pour le fonctionnement de ma boite (genre ERP) ai-je le droit de courir le risque de me retrouver sans support ?
    Je paye une fortune à TRUC, mais j’aurai une solution de support. C’est l’assurance-vie de ma boite.

    D’un autre côté, j’ai trouvé un open-source génial, qui fait exactement ce que je veux … mais au bout de 4 ans le développeur a perdu l’intérêt dans le produit (il a un nouveau job ou lancé un nouveau projet) et l’on se retrouve coincé avec un soft qui ne veut plus marcher la dernière version de Java ou qui n’a pas pris en compte l’évolution de la loi sur la TVA…

    De même pour de l’infrastructure : Linux fait ce que je veux et il n’y a pas mieux pour mes serveurs. Mais c’est tellement vital et critique pour ma boite, que je suis obligé de prendre des contrats de maintenance chez RedHat. Et là, on rejoint des coûts du monde des solutions propriétaires.

  2. Joyce Markoll

    > On ne peut généralement pas récupérer un projet open-source pour le
    revendre avec licence en suivant, même en ayant modifié quelques lignes
    de code

    Bonjour,

    Les licences libres au sens de la FSF le permettent. Donc, si, on peut ! Par contre en pratique c’est assez peu pratiqué de par la nature même du logiciel. Une information officielle:
    http://www.gnu.org/licenses/gpl-faq.html
    (à lire, à partir de “Est-ce que la GPL m’autorise à faire payer des exemplaires de mon
    programme ? (#DoesTheGPLAllowMoney)”)

    Ce qui n’est pas Ok, pour un logiciel sous licence GPL ou reconnue par la FSF comme une licence libre, est d’enfermer du code libre dans du code propriétaire. Par contre, les licences BSD le permettent. Bref, le monde des licences est loin d’être binaire ! :)