Ce qu'il faut savoir.
À la suite du plateau «L'open source en entreprise : alors, c'est possible ?» j'ai rédigé un premier billet pour reprendre certaines affirmations du débat. En complément, j'ai eu envie de rédiger ma vision des choses (j'ai repris des éléments du plateau et des notes de préparations, que j’ai illustrés et complétés)
L'objectif de ce billet est de donner des clés pour comprendre l'open source. Bien souvent, ce genre de débat est passionné, nourri de vieilles rancoeurs et de méfiance. On oppose open source et logiciel propriétaire. Mais on oppose aussi open source et logiciel libre rendant le débat encore plus difficile à suivre.
Beaucoup d'entreprises s'interrogent sur l'opportunité d'utiliser une solution open source. C'est un phénomène en pleine expansion qui est beaucoup plus qu'un effet de mode. Pourtant, l'open source n'est pas LA solution pour toutes les entreprises. Mais avant de pouvoir évaluer l'intérêt ou non d'une solution open source pour son entreprise, il est très important de bien comprendre de quoi il s'agit.
Après une courte définition pour poser le cadre, je traite la question de savoir pourquoi l’open source existe. Comprendre les motivations des entreprises qui développent en open source permet de voir que le mouvement est très divers et que les motivations ne sont pas toujours les mêmes. À partir de là, le point crucial est le suivant : quels sont les avantages et les inconvénients pour le client et/ou l'utilisateur final.
Vraisemblablement chaque point pourrait être beaucoup plus développé (d’autant plus que certains peuvent faire débat). Je suis loin de connaître en détail tous les exemples d'illustration. J’espère néanmoins que pour une première approche, il n’y a pas trop d’inexactitude. N’étant moi même pas un expert du domaine, je suis ouvert à tout retour constructif dans les commentaires.
Un logiciel open source réponds aux critères définis par l’Open Source Initiative qui garantissent la possibilité :
L’accès au code source (par exemple si celui-ci est lisible, dans le cas d’un programme consistué de script) n’en fait pas un logiciel open source. De même, le fait d’être gratuit ne rend pas un logiciel open source et un logiciel open source peut être payant.
Dans la pratique cela passe par l’utilisation d’une licence qui donne un habillage juridique fort. Par exemple si un développeur déclarait que son travail était libre de droit, soumis à aucune contrainte, un éditeur pourrait reprendre ce travail et faire payer les personnes qui l’utilisent. Les licences accordent des droits, mais précisent également les limites d'utilisation du programme et des sources. Sans entrer dans les détails, il existe plusieurs types de licences (pour des raisons historiques, mais aussi pour défendre des approches différentes). On distingue les licences «virales» qui forcent l’ensemble du travail à être distribué avec la même licence (typiquement la GPL), des licences «non virales» qui acceptent l’intégration du travail dans un logiciel non open source (par exemple les licences type BSD ou Apache).
Les projets open sources sont très variés et il est très difficile de les catégoriser précisément. Quelques critères peuvent servir :
Sans entrer dans l’énorme polémique de la différence entre logiciel libre «free software» et «open source» qui n’intéresse que les spécialistes, on peut dire que les logiciels libres sont des logiciels open source particuliers: l’objectif recherché par le logiciel libre n’est pas le même et les contraintes plus importantes (certaines licences considérées open source par l’Open Source Initiative ne sont pas acceptable comme licence de logiciel libre par la Free Software Fondation). Malgré ces oppositions (non négligeables tout de même), les licences sont proches, le mode de fonctionnement et de développement est semblable et très différent du modèle des entreprises qui font du logiciel propriétaire.
Les entreprises ne sont pas phlanthropes, les développeurs ont besoin d’argent pour vivre (ou alors, ne sont pas très disponibles, car la programmation n’est pas leur activité principale). Les différentes raisons ne sont pas forcément uniques. Parfois la stratégie est tout à fait définie et pensée en amont du projet, alors que dans d’autres cas, les raisons évoquées peuvent être une conséquence, une modification de stratégie ou une réaction par rapport à la concurrence. On le voit dans les exemples donnés : certains pourraient être donnés en illustration de plusieurs raisons.
Si s'agit d'une librairie ou d'un outil qui n'est pas stratégique pour l'entreprise, le placer en open source peut permettre de mutualiser l'effort de développement, d'amélioration du produit.
Pour rallier une communauté de développeurs, d'utilisateurs (avec parfois dans l'idée de leur vendre la version prémium, ou des services associés).
Parce que c'est compatible avec le business modèle de l'entreprise qui vend du service ou des projets basés sur une technologie.
L'obligation légale de la licence (dans le cas où une partie du développement est basé sur des technologies open source)
Cohérent avec le type de structure: par exemple une université qui veut placer ses résultats de recherche. Une association/fondation dont le but est de créer des logiciels ou des librairies Open source.
Un intérêt stratégique supérieur comme le fait de bousculer la concurrence sur un secteur déjà bien encombré ou de démontrer que le logiciel fait ce qu'il dit.
Assurer une deuxième vie au projet. Pour les logiciels en fin de vie, ou ne représentant plus d'intérêt pour l'entreprise.
Gagner de la notoriété en terme d'image, de publicité…
La passion, conviction
Au final lorsque l'on est client ou utilisateur de produit open source, la raison pour laquelle le projet est open source n'est qu'un facteur parmi d'autres. Ce qui compte c'est les avantages et les inconvénients. L'open source n'est pas forcément la solution.
En fonction des projets open sources, certains des avantages ou des inconvénients sont plus ou moins vrais. Plus important encore, en fonction du client, de ses ressources et de ses objectifs, cela va avoir plus ou moins d'importance. Enfin, il y a aussi une grosse différence entre un logiciel fini ou juste une librairie.
Maîtrise du code, certaine assurance.
Intelligence collective (développement, relecture du code, rédaction de documentation…).
Possibilité d’avoir un effet moteur sur le projet, pour le faire aller dans le sens désiré.
Prix d'entrée souvent plus bas.
Difficulté d'évaluer la pérennité d'un projet open source. Trouver les bons indicateurs n'est pas simple.
Les règles du jeu sont variables dans le temps. Les projets peuvent changer de mode de distribution. Le soutien d'une grosse entreprise peut s'arrêter (exemple de Sun/Oracle qui ne soutient plus OpenSolaris).
Les acteurs sont plus divers, et pas tout le temps facile à identifier. Bien souvent, il n'y a pas une société éditrice unique. Le mode de développement n'est pas identique pour tous les projets (prendre en compte la communauté ou non, travailler avec une road-map précise ou non) et peut ne pas correspondre à l'objectif.
L'offre n'est pas facile à lire, certains projets se séparent en plusieurs branches (fork) à la suite de désaccords, rendant l'offre encore plus nombreuse.
Certains logiciels peuvent être restés en chantier, ou ne plus être maintenus. Certaines feuilles de route ne sont pas du tout respectées.
La licence peut être trop contraignante par rapport aux objectifs de l’entreprise (redistribution d’un travail distribué …).
Un logiciel non patché, ou non mis à jour peut être plus vulnérable du fait que son code source est disponible et peut servir à la création d'exploit (en même temps avec un logiciel propriétaire très répandu, on se retrouve dans le même cas).
Il n'y a pas forcément d'économie pour le client (les frais sont ailleurs que dans la licence)
Le fait de disposer des sources peut n'être qu'une faible garantie (le logiciel peut être impossible à reprendre, ou à faire évoluer. Beaucoup des utilisateurs d’OpenOffice.org ou de Firefox n’ont pas les ressources pour faire quoi que ce soit)
En relisant les notes préparatoires du plateau, on trouve de très nombreuses questions qui à mon avis n'ont pas trouvé de réponses dans le débat. Mon analyse avantages/inconvénients pour le client est trop succincte, absolument non professionnelle (un DSI aura certainement une approche plus précise), et devrait être adaptée à chacun des projets open source envisagés. De plus, il y a une vraie demande d'exemples et de comparatifs avec des cas réels à l'appui.
Il y a besoin de pédagogie dans ce domaine qui est loin d'être simple, mais je pense avoir ouvert le débat. À quand les prochains plateaux sur TechTocTv ?
Draft version (projet pour le blog de TechTocTv), © Tout droits réservés, Jérémie Bresson