Les limites du modèle Open Source

Chez Solution Gestion Projets, nous considérons normal qu’une entreprise paie pour les logiciels qu’elle utilise, lorsqu’ils apportent de la valeur. Il faut bien payer les équipes de développeurs !

Le modèle Open Source est très attractif sur le papier, mais se heurte à des limitations importantes. En premier lieu, les équipes de développement sont formées sur la base du volontariat ou d’une forme intellectuelle de crowdsourcing. Résultat, il n’existe pas de possibilité de mettre en place une gestion de la qualité digne de la qualité. Difficile de refuser les bonnes volontés, encore plus difficile de s’en séparer lorsqu’elles posent problème. Puisque tout le monde peut contribuer, n’importe qui peut contribuer. Le risque existe même que des programmeurs mal intentionnés introduisent des vulnérabilités dont ils pourront se servir plus tard.

La gestion d’une équipe de développeurs Open Source bénévoles peut donc se révéler cauchemardesque, même lorsqu’une équipe réduite en forme le noyau.  Conséquence, les mises à jour sont difficiles à planifier : l’Open Source ne permet pas une anticipation facile. Les additions successives, le manque de contrôle et de transparence, la complexité inhérente aux équipes de développeurs bénévoles qui ne disposent pas d’un gestionnaire de projet, se traduisent fréquemment par du « bloatware », des logiciels aux fonctions inutiles et superfétatoires ;

En outre, la gestion de la propriété intellectuelle peut poser des problèmes très complexes. Une licence « Open Source » reste une licence ; mais son périmètre d’application est bien souvent assez flou et exige d’être soigneusement examinée par un avocat spécialiste afin de déterminer les limites de ce qui est permis. En effet, il n’existe pas véritablement de standard, même si l’Open Source Initiative tente d’en imposer un. La variété des licences Open Source est telle qu’elles pourraient remplir un livre complet.

Par ailleurs, la conformité des applications avec la politique interne de l’entreprise – notamment au regard de la sécurité – est complexe à valider.  La plupart du temps, une entreprise qui désire adopter un modèle Open Source devra s’adjoindre les services d’une entreprise commerciale qui fournira un support payant. Open Source ne signifie donc pas toujours « gratuit » tandis que logiciel propriétaire ne signifie pas toujours « payant ».

Dernier point, et non des moindres : l’interface des logiciels Open Source se révèle le plus souvent médiocre sinon catastrophique. La communauté de développeurs prête bien souvent plus d’attention aux fonctionnalités qu’à l’aspect utilisateur final. Lorsque l’on sait la part importante que l’UX (User Experience, ou ressenti utilisateur)  revêt dans l’adoption et le succès d’un logiciel, on mesure la difficulté que génère cette approche.

À contrario, des logiciels simples à exploiter voient leur adoption facilitée, c’est ce qui explique en partie le succès d’Apple avec des produits très ergonomiques. Cet argument est souvent mal accepté par les défenseurs de l’Open Source, qui mettent en avant l’éventail de fonctionnalités et la gratuité. Nous ne partageons pas du tout cette opinion. Un logiciel d’usage général (c’est-à-dire non destiné aux programmeurs, codeurs, personnels IT) qui exige que l’utilisateur s’adapte constitue pour nous un mauvais logiciel. Pourquoi ? Tout simplement parce que l’efficacité personnelle se trouve largement réduite et se traduit par des pertes de temps importantes. Une licence commerciale à 30 euros par utilisateur et par mois sera donc largement préférable à une licence Open Source qui fait perdre 5 à 10  heures par mois, soit bien plus que 30 euros, à chaque utilisateur en raison d’une ergonomie déplorable.

Les entreprises l’ont souvent bien compris. Voici une bonne dizaine d’années, le monde de l’IT bruissait des nouveautés de Linux, et prédisait la fin imminente des OS propriétaires. Aujourd’hui, Windows 10 vient de sortir et connaît un taux de pénétration satisfaisant, MacOS n’a jamais été en si bonne forme (certes il est basé à l’origine sur Unix, mais constitue bien un OS propriétaire commercial). Quand à Linux, son adoption se limite à la communauté des développeurs et à la gendarmerie nationale.

Il est vrai que ce n’est pas le cas pour les serveurs web, dont l’immense majorité tourne sur des systèmes Open Source dit LAMP (Linux,  Apache, MySQL). Mais si l’on prend l’ASF (Apache Software Foundation), ses conditions d’admission des développeurs sont draconiennes et ressemblent tout à fait à celles d’une entreprise de logiciel classique. Ajoutons que la dimension technique d’un stack LAMP est bien présente, ce qui n’est pas le cas d’un CRM ou d’un système de gestion de projet Open Source destiné à des non-techniciens de la programmation et du code.

Pour finir, les limites de l’Open Source et des logiciels propriétaires sont parfois floues ou complexes. Si l’on reprend le cas d’Apple, son OS est basé sur un système Open Source (Unix) mais l’interface est propriétaire. De même, Android de Google fait appel à de l’Open Source et peut se voir édité par les fabricants de smartphones qui l’achètent, mais ces versions ne sont pas supportées par d’autres développeurs Open Source, et les Android personnalisés comme celui de Sony ou de Samsung deviennent des facto une sorte d’Open Source propriétaire.

Pour résumer, certaines licence Open Source (comme Apache) peuvent se révéler utiles et efficaces, notamment lorsqu’elles s’adressent aux personnels IT ; d’autres (comme Open Office) peuvent rendre des services inférieurs à ceux rendus par les solutions commerciales, et d’autres peuvent conduire à des résultats sous-performants.  Et si les Français aiment souvent parler d’Open Source, comme une sorte d’étendard de la liberté, ces considérations idéologiques n’entrent pas dans notre champ d’action : nous souhaitons informer nos lecteurs sur la performance, pas sur l’idéologie.

Dans nos tests, nous ne prenons donc jamais en compte la dimension Open-Source. Encore une fois, nous estimons qu’une entreprise devrait payer pour l’utilisation d’un logiciel qui ajoute de la valeur à son système d’information.

Author: Charles

Charles est le rédacteur en chef de Solution Gestion Projets. Spécialiste en ingéniérie sociale, c’est un geek qui aime tout ce qui touche à internet. Il a derrière lui un lourd passé de programmeur…

Share This Post On

2 Comments

  1. Bonjour,
    Je viens de lire vos réponses aux commentaires sur un logiciel libre (odoo mais peu importe) dans lequel vous martelez qu’il faut des éléments factuels pour établir un commentaire ou critiquer, etc…
    Et en cliquant sur un lien en bas que vous avez mis vous même je tombe sur l’article ci-dessus !!!
    Cet article est juste un assemblage de lieux communs du genre « Résultat, il n’existe pas de possibilité de mettre en place une gestion de la qualité digne de la qualité. Difficile de refuser les bonnes volontés, encore plus difficile de s’en séparer lorsqu’elles posent problème. » et je ne cite qu’un des passages !
    Je vais faire comme vous :
    – pouvez vous me démontrer que le logiciel est un modèle incapable de produire un logiciel de qualité ?
    – et si jamais vous avez envie de chercher factuellement un peu de positif dans les logiciels libres, pouvez-vous trouver un logiciel libre qui ait atteint un niveau de qualité acceptable ? (allez, je vous aide un peu : regardez dans les logiciels propriétaires qui sont sur votre PC s’il n’y aurait pas quelques bouts de logiciels libres à l’intérieur …).
    Hervé (un lecteur déçu)

    Post a Reply
    • En quoi cet élément cité est-il un lieu commun?
      Vous défendez le logiciel libre, aucun problème. Personne ne dit que l’open source ne permet pas de produire un logiciel de qualité. Mais l’open source souffre de limites bien compréhensibles,

      Post a Reply

Submit a Comment

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *