| Un article de Mirasol Op'nWorks |
Le phénomène du code source libre ("open source") est en train de révolutionner l'industrie du logiciel. Plusieurs organisations et généralement pas les plus petites, ont résolument fait le pari du code source libre tant comme concepeurs/fournisseurs que comme consommateurs/utilisateurs de solutions. Malgré cela, le phénomène reste mystérieux et difficile à comprendre par les observateurs et en particulier par les gestionnaires qui ont à avaliser (ou non), l'adoption d'une solution bâtie en tout ou en partie avec du code source libre. Ce document vise à démystifier le phénomène et à mettre les choses en perspective lorqu'on discute des mérites ou des limites du modèle à code source libre.
Mythe #1 : Les logiciels à CSL ne sont pas sécuritaires
Mythe #2 : Les logiciels à CSL sont mal supportés
Mythe #3 : Les logiciels à CSL sont mal documentés
Mythe #4 : Les logiciels à CSL sont réservés
aux hackers
Mythe #5 : Les logiciels à CSL risquent de se retrouver
orphelins
Mythe #6 : Les logiciels à CSL sont de moindre qualité
Mythe #7 : Le mouvement du CSL n'est pas viable et va s'effondrer
Malgré un grand nombre de faits et d'exemples indiquant au contraire que la sécurité des logiciels à CSL est généralement plus grande que celle des logiciels commerciaux, ce mythe est tenace. Il provient essentiellement d'un principe voulant que le secret constitue une protection efficace. En d'autres mots : si personne ne connaît le code source d'un programme, personne ne peut le " craquer ". Les preuves du contraire sont nombreuses et on en obtient de nouvelles tous les jours. Combien de solutions " secrètes " visant à protéger les droits d'auteurs et à empêcher le piratage de logiciels ont passé l'épreuve du feu et ont résisté, même quelques mois, aux efforts des cyberpirates? Combien de vulnérabilités pour des logiciels fermés ont été identifiées suite à des intrusions? Plusieurs auteurs affirment, au contraire, que les logiciels à CSL sont généralement moins vulnérables parce qu'ils sont exposés à l'œil critique d'un plus grand nombre de programmeurs et que les correctifs sont développés, testés et déployés plus rapidement grâce, notamment, au mode de développement utilisé pour le CSL.
[ Haut ]
Cette perception vient en partie du fait que les gestionnaires ne se font pas
nécessairement offrir, d'emblée, un contrat de support pour un
logiciel à CSL. Par contre, discutez avec n'importe quel développeur
ou programmeur chevronné et il vous dira généralement qu'il
obtient un meilleur support d'une communauté open source active et dynamique
que d'un fabricant de logiciel aussi gros soit-il. Les raisons pour cela sont
nombreuses et incluent le fait que le support chez les fabricants est généralement
confié à des juniors qui ont pour mission de permettre à
l'équipe de R&D de ne pas être dérangée. Mais
au delà de cela, le simple fait d'avoir accès au code source permet
de mieux comprendre l'origine du problème, non seulement par le programmeur
qui le rencontre mais par tous les membres de la communauté de développeurs/utilisateurs.
Dans les faits, le support vient de la communauté et on réussi
généralement plus facilement à entrer en contact avec quelqu'un
de compétent que lorsqu'on a un contrat de service à moins que
celui-ci soit de type ultra-platine auquel cas, on paye généralement
très cher.
D'autre part, pour virtuellement tous les logiciels à CSL, on peut trouver
du très bon support et un accès privilégié à
ce support si on est prêt à payer. Les personnes qui développent
du code sous licence libre sont généralement très contentes
de se faire payer pour faire évoluer le code et supporter les utilisateurs.
Pour les logiciels à CSL les plus populaires, il est très facile
de trouver une organisation offrant du support technique et/ou de la formation.
[ Haut ]
Encore une fois, il est vrai que bien des logiciels à CSL pour laquelle la communauté est petite ou émergeante sont peu ou mal documentés. Mais on peut faire le même constat pour bien des logiciels commerciaux. Par contre, pour les logiciels à CSL matures et populaires, on trouve généralement autant sinon plus de livres et de documentation et de meilleure qualité que pour les produits vendus. En fait, la vente de livres est un des modes de financement des développeurs et des spécialistes et comme n'importe qui a facilement accès à la technologie, la concurrence entre les éditeurs est généralement vive. De plus, on constate que les auteurs sont moins complaisants que les rédacteurs techniques embauchés par les fabricants de logiciels et donc, qu'ils n'hésiteront pas à décrire les faiblesses ou problèmes dont souffre le produit.
Pour simplement illustrer le phénomène décrit ci-haut, une recherche de livres traitant de MySQL (un logiciel de base de données à CSL) sur amazon.com a produit 70 titres. Une requête pour des livres sur DB2 (une solution commerciale) génère 144 titres. Le premier logiciel est beaucoup plus jeune et certainement moins utilisé à ce jour que le 2e et, pour cette raison, le résultat n'est pas trop surprenant. Par contre, si on limite la recherche aux livres publiés au cours des derniers 12 mois, la tendance est inversée : on trouve 15 livres sur DB2 et plus de 30 livres sur MySQL. Tirez vos propres conclusions!
[ Haut ]
C'est un secret de polichinelle parmi les développeurs Java, notamment,
que virtuellement toutes les organisations qui ont des équipes de développement
utilisent des logiciels à CSL souvent à l'insu des gestionnaires.
Plus souvent qu'autrement, les logiciels achetés à grands frais
auprès des fabricants exploitent eux-mêmes des bibliothèques
et des composants à CSL. Dans le monde Java, à tout le moins,
plus de la moitié quand ce n'est pas la totalité des outils de
développement utilisés sont des produits à CSL. En production
également, les solutions proposées par les vendeurs intègrent
généralement des composants à CSL.
Une partie du modèle économique se trouve là : les organisations
se font vendre des solutions qui sont, en partie du moins, disponibles gratuitement.
D'autre part, comme les fabricants ont besoin de ces composants dans leurs solutions,
ils contribuent à l'effort de développement de la dite composante.
[ Haut ]
L'argument souvent entendu est le même que pour les solutions provenant de petits fabricants : si le fabricant disparaît pour une raison ou une autre, je vais me retrouver avec une solution orpheline. Le risque qu'un logiciel pour lequel il n'y qu'une très petite communauté soit délaissé et finisse par sombrer dans l'oubli de tous est réel. Par contre, si l'organisation utilisatrice en a réellement besoin, elle a toujours l'opportunité de reprendre le flambeau et de garder le produit en vie.
De plus, il y a très peu de produits logiciels, commerciaux ou à CSL, pour lequel le risque d'orphelinage est nul. Les fabricants décident régulièrement d'abandonner un produit et à ce moment, l'organisation qui utilise celui-ci se trouve plus souvent qu'autrement avec le besoin de remplacer la solution à ses propres frais. On a même vu certains fabricants publier leur code sous licence à CSL dans le but précis de la garder en vie et de réduire les coûts de développement et de support du produit ou dans une tentative d'augmenter leur part de marché.
[ Haut ]
Les gens avisés savent pertinemment que le fait qu'un logiciel soit développé par une entreprise qui vend des licences d'utilisation n'est pas une garantie de qualité. En fait, en ne divulguant pas leur code source, les entreprises laissent très peu de moyens aux clients pour évaluer la qualité de leurs produits. Il existe évidemment des solutions à CSL mal conçues et mal construites. L'utilisateur potentiel a deux avantages : il peut faire un audit du code en question avant de l'adopter et au besoin, il peut même corriger et améliorer le dit produit.
On peut sans trop se tromper affirmer que la qualité moyenne du code utilisé sous licence à CSL est supérieur à la qualité moyenne du code utilisé sous licence à code fermé. Dans le monde de l'open source, un code trop brouillon ne passera tout simplement pas la rampe, il ne retiendra pas l'intérêt des développeurs ou des utilisateurs et restera tout simplement une curiosité.
[ Haut ]
Ce mythe provient d'un autre mythe voulant que l'industrie du logiciel soit
une industrie manufacturière. Hors, ce n'est pas le cas. On doit plutôt
parler en premier lieu d'une industrie de services ou la grande majorité
des professionnels sont à l'emploi soit de sociétés ou
d'organisation dont la mission n'est pas de fabriquer et de vendre des logiciels
soit de sociétés dont la mission est d'offrir des services conseils
aux autres organisations. Les logiciels à CSL sont créés
et entretenus en grande partie par cette partie de l'industrie.
De plus, même les fabricants de logiciels dépendent aujourd'hui
de la disponibilité de produits sous CSL et la disparition de ceux-ci
les obligeraient à recréer l'équivalent à grands
frais et à grands risques techniques et commerciaux. Il y a aujourd'hui
tellement d'individus et d'organisations qui ont un intérêt vital
dans plusieurs solutions à CSL que le mouvement ne court aucun risque
d'essoufflement ou de désuétude.
[ Haut ]