[NEWS] Les mythes de l'Open Source
Deux articles en anglais parus courant du mois de décembre 2003 démontaient quelques mythes relatifs à l'Open Source. Ils étaient assez complémentaires puisque le premier s'attaquait aux mythes existant à l'extérieur de la communauté tandis que le second le faisait pour ceux qui persistent en son sein.
Quelques mythes relatifs à l'Open Source en général
Premier mythe : « L'Open Source Software fonctionne en tout ou rien. Vous devez choisir entre n'utiliser que des logiciels Open Source ou que des logiciels propriétaires. »
En réalité, vous pouvez utiliser un mélange de logiciels propriétaires et Open Source. Vous pouvez même utiliser des logiciels Open Source sous Windows. Il ne faut pas perdre de vue le fait que l'Open Source est une philosophie alternative de création et de distribution de logiciels, pas une technologie à part.
Second mythe : « La centralisation du développement logiciel est toujours mieux. »
En réalité, la nature distribuée du développement Open Source (communauté) permet une réaction rapide en cas de problèmes (nécessité de sortir un correctif, par exemple) et le brassage d'un grand nombre d'idées. La popularisation de la formation en informatique contribue à augmenter le nombre de contributeurs potentiels.
Troisième mythe : « Vous obtenez ce pour quoi vous avez payé. »
En réalité, une entreprise possède une enveloppe budgétaire fermée. Si un produit se révèle rentable et porteur en terme d'image, elle allouera plus de ressources pour son développement. Et inversement. La logique diffère pour les logiciels libres. Ils attirent de nombreux développeurs talentueux, sans considération mercantile.
Quatrième mythe : « Les logiciels Open Source ne sont pas sécurisés. »
En réalité, la disponibilité du code facilite la détection des exploits. Etant donné une communauté suffisamment grande (nous verrons plus bas que cette condition est plus l'exception que la règle !), le travail de fixation des bogues est à l'avantage des logiciels Open source.
Cinquième mythe : « Les logiciels Open Source conviennent seulement pour les fanatiques et les petites entreprises. »
En réalité, tout l'internet est construit sur les logiciels libres. De grandes entreprises les ont également adoptés. Globalement, les logiciels Open Source sont utilisés par des entreprises, des gouvernements et l'enseignement. Il faut d'ailleurs garder à l'esprit que 24% des sites Internet sont écrits en PHP, 65% des sites Internet tournent sous Apache, 76% des serveurs de courriels sont sous Sendmail, 90% des domaines sont contrôlés par BIND et que 99% de tous les navigateurs Internet sont basés sur le navigateur NCSA Mosaic !
Mr. Smith, auteur de l'article paru sur le site Line56, conclut en soulignant quelques avantages complémentaires des logiciels Open Source comme l'absence de période d'essai. Nous nous devons par contre de relativiser ses arguments de gratuité et de permissivité. D'une part, s'il n'y a généralement pas de coût d'acquisition, la gratuité n'est pas une obligation (« Free as free speech, not as free beer »). Par ailleurs, il convient de ne pas négliger d'autres formes de coûts, comme les prestations de services (pour une migration ou une intégration, par exemple). D'autre part, dire qu'il n'y a « rien à approuver » pour obtenir un logiciel Open Source est abusif. Un logiciel Open Source est ainsi accompagné de sa licence, qui fixe les droits et les devoirs de chacune des parties.
Quelques mythes relatifs au développement de logiciels Open Source en particulier
Premier mythe : « Diffuser publiquement du code Open Source entraînera un afflux massif de correctifs et de nouveaux contributeurs. »
En réalité, vous serez heureux d'apprendre que quelques personnes utilisent votre code et que seule une faible fraction d'entre elles est effectivement intéressée par sa modification.
Second mythe : « Arrêter un nouveau développement pour quelques semaines ou quelques mois pour corriger les bogues est le meilleur chemin pour produire un code stable et soigné. »
En réalité, stopper pour quelques temps un nouveau développement dans le but de corriger des bogues inconnus est bien. Néanmoins, c'est seulement un aspect de l'écriture d'un bon logiciel.
Troisième mythe : « Les nouveaux développeurs intéressés par un projet préféreront apprendre de ce projet en corrigeant des bogues et en lisant le code source. »
En réalité, la lecture d'un code est difficile. Corriger des bogues est difficile. Il s'agit de quelque chose que vous ne voulez pas faire de toute façon. Bien que le fait de donner à quelqu'un un travail sans attrait permette de tester son dévouement, il dépend d'un apprentissage non structuré par osmose. Un projet nécessite une vue d'ensemble.
Quatrième mythe : « L'installation et la configuration ne sont pas aussi importantes que le fait de rendre le code source disponible. »
En réalité, si cela prend trop de temps pour simplement faire fonctionner le logiciel, beaucoup de gens abandonneront sans bruit.
Cinquième mythe : « Un code mauvais ou peu attrayant devrait être complètement jeté. »
En réalité, résoudre les mêmes problèmes encore et encore est un gaspillage de temps, qui pourrait être employé à résoudre des problèmes nouveaux et plus importants.
Sixième mythe : « C'est mieux de fournir une structure pour beaucoup de monde pour résoudre beaucoup de problèmes que de résoudre correctement un seul problème. »
En réalité, il est très dur d'écrire une bonne structure avant que vous ne l'ayiez réellement utilisée pour résoudre au moins un problème concret.
Septième mythe : « Même si votre précédent code était bogué, non documenté, difficile à maintenir ou lent, la version suivante sera parfaite. »
En réalité, si vous n'étiez pas discipliné auparavant, pourquoi le seriez-vous maintenant ?
Huitième mythe : « Les avertissements sont juste des avertissements. Ce ne sont pas des erreurs et personne ne fait réellement attention à eux. »
En réalité, les avertissements (warnings) peuvent cacher de vrais problèmes, en particulier si vous y êtes habitués.
Neuvième mythe : « Les utilisateurs ne pensent pas à acquérir la dernière version en provenance du CVS pour corriger un bogue ou apporter une caractéristique depuis longtemps attendue. »
En réalité, si c'est difficile pour vous de fournir des correctifs importants pour les versions précédentes, votre arbre CVS ne sera probablement pas très stable.
Ce deuxième article apporte un regard complémentaire à celui, pionnier, d'Eric Raymond ("La cathédrale et le bazar"), dont un aperçu est donné ici.
Sources :
[1] Smith JT, The OSS Fear Factor, Line56.com, 23 décembre 2003.
[2] Myths Open Source Developers Tell Ourselves, OnLamp.com, 11 décembre 2003.
12/11/2003
Posté le 16 février 2004.
|