|
02/07/2001
Pourquoi les projets Open Source
sont supérieurs
par
Alain Lefebvre, vice-président du groupe SQLI (www.sqli.com)
Le
mois dernier, j'avais conclu ma chronique
"Décryptage" par deux affirmations : la qualité
(et donc la fiabilité) des projets Open Source (ou OSS pour
Open Source Software) est bien meilleure que celle des projets
propriétaires et leur pérennité est sans commune mesure. Examinons
cela dans le détail
Pourquoi
un tel engouement pour les logiciels à code source ouvert
? Les arguments techniques en faveur des OSS sont nombreux
et solides. Voici rassemblées ici quelques-unes des questions
les plus habituelles comme "les OSS sont-ils performants ?",
"les OSS sont-ils fiables ?", "les OSS sont-ils supportés
?"
1.
Les OSS sont performants
 |
|
|
En se
penchant sur le fonctionnement de Linux, on obtient une réponse
globale sur la qualité d'ensemble des projets OSS car ce système,
devenu très populaire ces derniers temps, peut être vu comme
un "concentré" d'OSS ! En effet, le noyau de Linux est complété
par toute une compilation des principaux projets OSS : Apache,
SendMail, Perl, Xfree, etc. Or, un bench "TPC-D" d'avril 1999
mettait justement Linux face à Windows NT avec Oracle 8 comme
base de données commune aux deux systèmes. Les résultats publiés
sur l'Internet démontraient un avantage de 2 à 20 fois en
faveur de Linux
Les conditions de ces tests étaient volontairement
simplifiées : configurations courantes des serveurs employés
et réglages par défaut des configurations logicielles. Le
but affiché était de mesurer le potentiel de l'un et de l'autre
quand ils sont mis en uvre par des non-spécialistes (typiquement
le contexte PME qui est une des cibles de ces environnements).
On peut toujours arguer que Windows NT (ainsi qu'Oracle8)
est très sensible au tuning et que les résultats pourraient
être radicalement différents avec une phase d'optimisation
approfondie
Certes, mais c'est un argument qui vaut aussi
pour Linux !
Un
portage réalisé dans de meilleures conditions grâce à l'ouverture
Comment expliquer que Linux se soit montré comme plus
rapide que NT pour faire fonctionner Oracle8 ? Tout d'abord,
les développeurs d'Oracle ont eu accès à davantage d'informations
sur les caractéristiques internes du système Linux qu'ils
n'en ont eu dans le cas de NT ; le portage a pu être réalisé
dans de meilleures conditions et le fonctionnement s'en ressent.
Ensuite, il est patent que Linux consomme moins de ressources
que Windows NT à machine égale. Tout simplement parce que
Linux est réellement modulaire car doté d'une architecture
propre et qui n'impose pas de fonctionnement incontournable.
Samba
a surpris les équipes de Microsoft
Ainsi, l'interface graphique est au choix et basée sur X-Window
mais, mieux encore, cette dernière ne se charge pas automatiquement
au démarrage et évite donc ainsi de consommer de la mémoire
inutilement dans le cadre d'un fonctionnement en serveur dédié.
A l'inverse, Windows NT lance automatiquement et obligatoirement
son interface graphique (module GDI) dès le boot et il n'est
pas possible de l'éviter
Enfin, les équipes de Microsoft
ont elles-mêmes mis Samba à l'épreuve. Elles ont été surprises
par son niveau de performance. Cela fut notifié dans un document
interne diffusé en 1999 (le fameux document "halloween").
Donc les OSS sont performants : la bonne tenue de Linux face
à Windows NT ou de PHP face à Java le prouve.
2.
Les OSS sont fiables
 |
|
|
Le Web
foisonne de témoignages multiples et diversifiés sur la fiabilité
constatée des logiciels OSS. Ces derniers sont souvent employés
pour des applications critiques et ils affichent un fonctionnement
de type "boot and forget" à la grande satisfaction de leurs
administrateurs ! On retrouve ainsi souvent Apache, Perl,
PHP, SendMail, Linux, FreeBSD et d'autres dans les configurations
des plus grands sites commerciaux du Web (Yahoo, Hotmail,
eBay, etc.) où la disponibilité est un point clé.
Autre domaine où la haute fiabilité n'est pas une option :
les équipements qui reposent sur de "l'informatique embarquée".
Ici aussi, on retrouve souvent Linux. Les spécialistes de
la sécurité informatique font également souvent confiance
à Linux pour mettre en uvre des firewalls. Principalement
parce que ce dernier offre un code ouvert, très "revu et corrigé"
ainsi que des correctifs fréquents et rapidement disponibles
dès qu'une faille est détectée.
Pourquoi les OSS bénéficient-ils d'une réputation de qualité
aussi flatteuse ? Sûrement grâce à l'approche "darwinienne"
des développements qui caractérise (entre autres) les projets
OSS ! Ainsi, les multiples développements parallèles sont
encouragés (ce que ne fera jamais un éditeur traditionnel,
d'abord par manque de ressources, ensuite pour éviter les
conflits entre les équipes) et, au final, seules les meilleures
contributions sont retenues par le groupe "noyau". Pourtant,
au départ ce mode de développement "collaboratif" heurte nos
convictions ancrées dans les habitudes et les idées-reçues
L'incontournable
"loi de Brooks" contredite
Dans "Le mythe du mois-homme", Fred Brooks observa qu'on ne
peut pas diviser et répartir le temps du programmeur; si un
projet a du retard, lui ajouter des développeurs ne fera qu'accroître
son retard. Il explique que les coûts de communication et
de complexité d'un projet augmentent de manière quadratique
avec le nombre de développeurs, alors que le travail réalisé
n'augmente que linéairement. Depuis, cela est connu sous le
nom de "loi de Brooks", et on la considère en général comme
un truisme. Mais si seule la loi de Brooks comptait, le développement
de Linux comme il s'est déroulé aurait été impossible.
Le classique
de Gerald Weinberg "La psychologie de la programmation sur
ordinateur" apporta ce qu'on pourrait considérer après coup
comme une correction vitale à Brooks. Dans sa discussion sur
la "programmation non-égoïste", Weinberg observa que dans
les sociétés où les programmeurs ne marquent pas le territoire
de leur code, et encouragent les autres à y chercher les bugs
et les améliorations potentielles, les améliorations sont
drastiquement plus rapides qu'ailleurs. Mais, encore plus
important que le développement initial, c'est surtout au stade
de la mise au point que l'effet d'échelle (d'un très grand
nombre de participants), caractéristique des projets OSS,
a une influence déterminante sur la qualité résultante
La
loi du plus grand nombre
Car
le debug est particulièrement efficace grâce à "la loi du
plus grand nombre" : étant donné un ensemble de bêta-testeurs
et de co-développeurs suffisamment grand, chaque problème
sera rapidement isolé, et sa solution semblera évidente à
quelqu'un. Ou, moins formellement, "étant donnés suffisamment
d'observateurs, tous les bugs sautent aux yeux". Les testeurs
sont largement plus nombreux que les développeurs et cette
grande exposition débouche sur une profondeur de correction
inconnue dans le cadre de projets commerciaux où la date de
lancement est souvent un élément inamovible primant sur tout
le reste.
Le
cercle fermé est inefficace
Dans la programmation menée de façon traditionnelle (petit
groupe travaillant en cercle fermé), les bugs et les problèmes
de développement représentent des phénomènes difficiles, ennuyeux,
insidieux, profonds. Il faut à une poignée de passionnés des
mois d'observations minutieuses avant de bien vouloir se laisser
convaincre que tous les bugs ont été éliminés. D'où les longs
intervalles séparant les mises à jour, et l'inévitable déception
quand on se rend compte que la mise à jour tant attendue n'est
pas parfaite. Dans un cadre de projet OSS, vous supposez qu'en
général les bugs sautent rapidement aux yeux lorsque de nombreux
contributeurs enthousiastes se précipitent sur toute nouvelle
mise à jour. C'est pourquoi vous mettez à jour souvent afin
de disposer de plus de corrections. Si ce principe était faux,
alors tout système aussi complexe que le noyau Linux aurait
dû s'effondrer depuis longtemps sous la masse des interactions
néfastes et imprévues et à cause des bugs "profonds" non découverts.
L'idée
reçue de la motivation par l'utopie
Certains diront "le développement des logiciels Open Source
repose sur la notion de communauté agissant par idéal. N'est-ce
pas dangereux pour le futur de ce mouvement et l'intérêt qu'il
représente en matière de qualité ?" Non, l'Open Source ne
repose plus seulement sur l'utopie désintéressée. Si les développeurs
contribuent, c'est d'abord qu'ils y trouvent leur intérêt
! Celui qui corrige un bug fait remonter sa correction afin
que le bug disparaisse pour de bon et ne risque pas de revenir
avec la version N+1. C'est ça la vraie logique vertueuse de
l'Open Source... Le modèle du développement collaboratif à
code source ouvert est le seul qui ait produit des résultats
tangibles en matière de qualité et de rapidité d'évolution.
C'est la notion d'ouverture totale qui est à l'origine de
ce changement d'échelle dans la production de logiciel.
Les détracteurs affirment aussi que les logiciels reposant
sur le développement collaboratif vont se fractionner en de
multiples versions incompatibles les unes avec les autres.
Le danger de fractionnement, s'il était réel, aurait déjà
produit ses effets. Or, c'est plutôt le contraire auquel on
assiste : des projets qui gagnent en sérieux au fur et à mesure
qu'ils étendent leur audience (documentations, spécifications
standards, support d'acteurs établis, etc.).
Distribuez
tôt, mettez à jour souvent
On peut donc "paralléliser le debug". Même si le
debug requiert que les testeurs communiquent avec un développeur
chargé de la coordination, une réelle coordination entre testeurs
n'est pas indispensable. Ainsi, le debug n'est pas la proie
de cette envolée de la complexité et des coûts d'organisation
qui rend problématique l'ajout de nouveaux développeurs. En
pratique, le monde des OSS n'est quasiment pas affecté par
la perte théorique d'efficacité qui découle du fait que plusieurs
testeurs travaillent sur la même chose au même moment. L'une
des conséquences de la politique du "distribuez tôt, mettez
à jour souvent" est de minimiser les pertes de ce type en
propageant au plus vite les corrections qui sont revenues
au coordinateur. C'est grâce à ces mécanismes que l'on constate
que la fiabilité des logiciels Open Source (due à la qualité
du code) est largement meilleure que celle constatée dans
les logiciels développés en circuit fermé
Suite
: 3. les OSS sont supportés >>
|
