Actualités

[09/06/2016] Eram booste ses ventes en ligne avec Smile

Smile accompagne l’enseigne Eram (leader de la chaussure en centre-ville et centres commerciaux) dans la mise en œuvre d’un site responsive design de nouvelle génération lui permettant de déployer à grande échelle sa stratégie de vente en ligne. Découvrez le témoignage !

[02/06/2016] Nouveau livre blanc Smile : Linux pour l’embarqué

Smile inaugure une nouvelle collection de livre blanc sur le thème de l'embarqué. Le premier de la série est consacré à l'utilisation de Linux embarqué dans les systèmes industriels.

[12/05/2016] HappyAtWork for Starters 2016

HappyAtWork for Starters est le premier label des entreprises où il fait bon débuter sa carrière. Il récompense l’excellence dans le management et la motivation des salariés avec la réalisation d’une enquête participative.

Toutes les actualités picto
       

Top consultation

Logo Smile : Open Source Solutions

Guillemet ouvrant introduction
à l'open source Guillemet fermant

Terminologie

Terminologie

Ce site est une introduction au phénomène de l’open source, la plus grande révolution qui touche l’informatique depuis l’Internet. Comme on le verra, le mouvement est bien antérieur au web, néanmoins la plus puissante perturbation sur l’économie de l’informatique date de ces dernières années, et ne fait que commencer.

Il a une vocation de vulgarisation, s’efforçant surtout d’expliquer l’open source à ceux qui n’y sont pas impliqués, mais commencent à en sentir l’importance, et ont besoin de mieux connaître le phénomène.

Terminologie

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 site serait pesant pour le lecteur, et avons pris le parti d’utiliser le terme open source. Notons toutefois que FLOSS est le terme officiel adopté par la commission européenne.


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é.

Dix ans plus tard, la cicatrice de cette scission n’est pas refermée entre logiciel libre et open source, 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, nous proposons ici notre 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. (...)


Bière gratuite

« Free » voulant dire à 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.

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.


Les bénéfices de l'open source pour le client

Pas seulement moins cher…

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.

La pérennité

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.

L’ouverture

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.

Pour en savoir plus >>

La sécurité

Le domaine de la sécurité mérite une mention spéciale. Car en matière de sécurité, l’accès aux sources est quasiment une obligation. On ne concevrait pas que l’armée française utilise pour ses communications un VPN reçu sous forme d’exécutable d’un éditeur américain ou chinois.

En matière de sécurité, il est absolument obligatoire de pouvoir auditer ce qu’un programme fait vraiment, et cela ne peut se faire qu’en analysant ses sources.

Pour autant, cela n’implique pas que le programme soit open source. Certains éditeurs non open source acceptent de livrer les sources à leurs clients, après signature d’un accord de non divulgation.

Mais il est un autre argument qui rend l’open source indispensable ici : le peer review, la validation des pairs, c’est à dire d’autres experts, et du plus grand nombre possible d’autres experts.

Faisons un petit parallèle. Dans ses débuts, la cryptographie utilisait majoritairement des algorithmes secrets. On considérait alors que la protection de l’algorithme contribuait à la sécurité. Dans l’après-guerre, une révolution s’est amorcée : on a finalement conclu qu’un algorithme secret, dont la qualité n’est affirmée que par la petite équipe qui l’a créé, avait de fortes chances d’être défaillant, si ce n’est aujourd’hui alors sans doutes dans quelques années. Et a contrario, les algorithmes qui sont exposés sur la place publique, sont analysés par des centaines d’experts dans le monde. S’ils ont une faille, elle est rapidement identifiée et connue. On peut donc en dire autant des programmes qui exécutent ces algorithmes : le meilleur moyen d’être assuré de leur perfection est de les exposer à l’audit de milliers d’experts.

Enfin ajoutons un dernier argument : en matière de sécurité, on préfère généralement les vieux algorithmes, qui ont fait leurs preuves, et on se méfie des dernières innovations. L’algorithme RSA date de 1977 ! Il est naturel que depuis ce temps, les programmes qui implémentent ces algorithmes soient parvenus dans le patrimoine commun, sinon dans le domaine public.

Il est donc naturel que le portail du gouvernement consacré à la sécurité informatique accorde une place importante au logiciel libre.

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.

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.