GAZETTE N°28: Rapport sur la conférence open source

Rapport sur la conférence open source

Par Guido van Rossum

Adaptation française : Roland Mas.

Précédent Suivant Table des Matières

7. Rapport sur la conférence open source

Mardi dernier s'est tenu le sommet sur le freeware open source, ainsi que la conférence de presse attenante. J'avais promis un rapport à quelques personnes, et j'ai décidé que je pourrais aussi le publier sur le forum de discussion dédié à Python.

Attention : cet article est biaisé, et peut contenir quelques erreurs, notamment sur les faits. Vous êtes prévenus ! Il est également plus long que je ne l'avais prévu, mais nous avons couvert un vaste domaine.

7.1 Contexte

Tim O'Reilly s'est rendu compte que les logiciels librement distribués sont de loin plus importants pour l'Internet que ne le pensent la plupart des gens, particulièrement les décideurs et ceux qui les informent (par exemple, la presse). L'impression générale est que l'Internet est construit en majeure partie sur du logiciel propriétaire, par exemple des produits de Solaris, de Netscape ou de Microsoft. En fait, de nombreux logiciels clefs ne sont pas propriétaires : 80 % du courrier transite par sendmail, la quasi-totalité des conversions de nom de domaine en adresse IP se fait par bind (Berkeley Internet Name Daemon), apache est le premier serveur Web du monde, le système de chiffrement le plus populaire est pgp, les trois langages de script les plus couramment utilisés sont Perl, Tcl et Python, et ainsi de suite.

Tous ces joyaux du logiciel sont librement disponibles sous forme de sources ! Qu'est-ce qui se passe ? Bien sûr, nous connaissons tous la réponse : c'est un superbe modèle de développement logiciel. Mais l'Amérique corporatiste met du temps à l'accepter. La divulgation des sources de Mozilla par Netscape a été la première indication que cela pourrait changer  et une fois ceci annoncé, O'Reilly a commencé à recevoir des coups de fil de la presse au sujet de ce mystérieux freeware, et s'est rendu compte qu'il y avait là une superbe occasion de mieux faire connaître le logiciel open source à la presse.

L'événement peut se découper en deux : pendant la journée, les développeurs invités ont discuté sur les mérites et les problèmes du logiciel open source, leurs plans etc. Puis, en fin de journée, nous avons tenu une conférence de presse. Je rapporterai les deux événements séparément.

7.2 Le sommet

En gros, les développeurs de logiciels qui étaient rassemblés ont parlé de 9 h à 17 h. Cela aurait pu durer toute une semaine, n'étaient les talents de modérateur de Tim O'Reilly. La plupart des participants venaient de Bay Area  personnellement, je suis venu de Washington, et John Ousterhout (qui y habite aussi) a interrompu ses vacances à Hawaii pour la journée.

Nous avons commencé par faire un tour de table des motivations et des expériences positives de chacun : pourquoi rendre les sources disponibles, ce qui marche bien, ce qui est apprécié au cours du processus. Nous sommes à la fin tombés d'accord sur les deux raisons proncipales pour lesquelles le modèle de développement open source fonctionne si bien. La plupart des autres raisons se réduisent à un cas particulier de l'une de ces deux.

Premièrement, du point de vue du développeur, il y a l'avantage du test massif (débogage en parallèle). Aucune autre méthode de développement logiciel ne produit des logiciels aussi fiables et robustes que l'open source.

Deuxièmement, du point de vue de l'utilisateur, le gros avantage est la flexibilité. Linus Torvalds le fait remarquer avec cet exemple : il est tout-à-fait satisfait du navigateur de Netscape, mais il a envie de désactiver les GIFs animés, qui ne servent pratiquement qu'à la publicité. Sans le source, il ne pourrait pas le faire ! (Jamie Zawinski, de Netscape, appelle ceci « se gratter là où ça vous démange ».)

Parmi les autres avantages du développement open source qui ont été évoqués, on compte le faible coût de la réutilisation des technologies, et l'utilisation d'une implantation de référence qui aide à développer un standard.

En ce qui concerne ce qui a poussé à diffuser les sources, un nombre étonnamment élevé (pour moi) de développeurs disaient que leur motivation, initiale ou ultérieure, était morale ou éthique : ils pensent que c'est faire « Ce Qui Est Bon » que de rendre les sources disponibles.

Le tour de table suivant fut consacré à nos expériences négatives : ce qui ne marche pas, ce qui pose problème et ainsi de suite. Mis à part les boutades comme « notre plus gros problème, ce sont les gens stupides », deux problèmes sont récurrents.

Premièrement, lorsqu'un logiciel se répand, son développeur passe plus de temps à en aider les utilisateurs qu'à le développer et l'améliorer. Même s'il existe des moyens d'éviter cela (par exemple, ne plus répondre aux courriers), le problème reste : sans organisation de suivi des utilisateurs, vous êtes grillés. Ceci se résume en « ruiné par la rançon du succès ».

Deuxièmement, il est souvent problématique de faire contribuer les personnes désireuses de le faire d'une manière utilisable. Le tableau le plus sombre a été brossé par John Ousterhout, qui dit qu'une amélioration écrite par un de ses contributeurs ne lui économise que 50 % du temps qu'il aurait passé à l'écrire lui-même. Certains étaient d'accord, d'autres (comme moi) firent la remarque que c'était un facteur variable. Certes, c'est vrai pour le noyau du logiciel, mais il existe de nombreux éléments périphériques pour lesquels beaucoup de code peut être accepté tel quel, même s'il ne marche pas, puisque les tests et débogages massifs le corrigeront une fois qu'il sera distribué. Linus a un point de vue extrêmiste mais très clair : les interfaces doivent être soigneusement conçues par le développeur principal, les implémentations peuvent être boguées. Par exemple, Linus ne trouve pas gênant que quelques pilotes de périphériques ne soient pas immédiatement stables (ils n'affectent qu'un petit nombre d'utilisateurs, et uniquement de manière temporaire), mais une mauvaise conception peut vous pourrir la vie jusqu'à la fin des temps. (Ceci recoupe mon expérience personnelle, mais Linus le formule mieux que moi.)

Ceci se résume à une affaire de contrôle. Il fut remarqué que la plupart des systèmes représentés ont un noyau gardé sous contrôle relativement strict par le dévelopeur principal et un mécanisme d'extension bien défini, tout en restant flexible, utilisé par la plupart des contributeurs, là où le contrôle est moins important.

Parmi les autres problèmes qui furent évoqués, on compte les lois actuelles sur la propriété intellectuelle, les abus qui sont faits pour les faire respecter d'étrange manière, et les diffamations injustes des logiciels open source par leurs concurrents qui essaient d'imposer des solutions propriétaires. Le modèle de distribution basé sur la vente n'est pas idéal : vous ne pourrez pas acheter la plupart des logiciels freeware chez votre revendeur informatique local, même à Palo Alto (Vous pourrez quand même trouver Red Hat Linux). La croissance du code a aussi été évoquée (mais les gens de chez Netscape ont fait remarquer que ce n'était pas un problème caractéristique des logiciels open source).

Après le déjeuner, nous avons discuté de ce que nous pourrions faire au sujet de ces problèmes.

Nous n'avons pas dit grand-chose de plus sur les problèmes de contrôle, sauf

pour remarquer que gérer une équipe de développement distribuée, comme les contributeurs à un projet open source de taille moyenne, ressemble un peu à rassembler des chats (La première fois que ce fut évoqué, j'avais entendu « frapper des chats » NdT : « herding cats » ou « hurting cats », en anglais, ce que j'ai trouvé un peu bizarre  heureusement, Tim et les autres gens de chez O'Reilly prenaient copieusement des notes sur un tableau blanc :-).) La meilleure contribution (à mon goût) fut celle d'Eric Raymond et John Gilmore (de chez Cygnus), qui notèrent qu'il est possible d'entraîner vos contributeurs (par exemple, par le biais de chartes de style, de standards de programmation etc.), et que c'est une méthode réellement efficace pour améliorer la qualité des contributions. Une manière de le faire est de garder les bribes de documentation au fur et à mesure que vous les produisez, par exemple en réponse aux questions par courrier des autres développeurs, et en quelques années, vous avez un guide du programmeur !

Le reste du temps (c'est-à-dire le reste de la journée), nous avons discuté de divers modèles économiques qui pourraient transformer l'open source en une activité rentable plutôt qu'un passe-temps ou une activité à l'intérêt discutable.

Il s'avère que presque tous les invités ont été impliqués dans une tentative de commercialiser leur logiciel  et tous voulaient le faire sans rendre leurs sources propriétaires. Toutes les situations étaient différentes, cependant  parfois à cause de la base des utilisateurs, parfois à cause de la concurrence, parfois pour des raisons légales, et parfois simplement parce que les motivations sont différentes.

Par exemple, John Gilmore nous exposa comment Cygnus a réussi à s'imposer en vendant des portages de GCC à l'industrie des systèmes embarqués, un petit marché de niche qui était, jusqu'à l'arrivée de Cygnus, monopolisé par un petit nombre de producteurs de compilateurs qui faisaient payer un million de dollars le portage d'un compilateur déjà existant vers un processeur à peine différent.

Une autre histoire d'un succès nous fut contée par Sameer Parekh de l'entreprise C2Net, qui vend Stronghold, une version commerciale et sécurisée d'Apache. La situation des brevets sur les logiciels de chiffrement est telle qu'aucun logiciel de chiffrement libre ne peut être utilisé à des fins commerciales. Les entreprises qui souhaitent un serveur Web sécurisé doivent donc le payer à un vendeur, quel qu'il soit. Remarquez que C2Net fournit les sources de sa version d'Apache à ses clients, sauf pour la bibliothèque de chiffrement, pour laquelle seuls les binaires sont fournis.

Encore une autre histoire vient de Paul Vixie, de l'Internet Software Consortium, une association à but non lucratif, qui s'occupe de Bind. De grandes entreprises ont payé de grosses sommes d'argent à l'ISC pour que Paul continue à développer Bind, et n'étaient pas gênées par la diffusion gratuite des sources aux autres entreprises, tant que le boulot était fait.

Il y avait aussi ceux pour qui il est encore trop tôt pour annoncer un succès (ou un échec) : Larry Wall et Linus Torvalds ne tirent aucun revenu direct de la vente de copies de Perl et Linux. D'autres le font cependant, et O'Reilly gagne pas mal d'argent en vendant des livres sur Perl, comme d'autres éditeurs. Linus a un emploi intéressant, non lié à Linux, chez Transmeta, et n'a pas prévu de commercialiser Linux personnellement  Larry, en revanche, travaille pour O'Reilly, et il y a des projets visant à commercialiser ne serait-ce que la version pour Windows (qui est réalisée par une société extérieure travaillant sous une sorte de licence avec O'Reilly).

John Ousterhout vient de franchir le pas vers le monde commercial pour Tcl/Tk, avec sa nouvelle entreprise Scriptics, formée après que Sun eu annulé ses projets de produits Tcl/Tk. John travaille sur un mélange d'open source et de logiciel propriétaire : Tcl et Tk en eux-mêmes resteront open source à jamais, mais Scriptics compte gagner de l'argent sur des produit propriétaires comme un débogueur et un analyseur de sources. Une raison de garder Tcl/Tk libre est qu'il s'assure ainsi de ne pas avoir à faire face à une version dissidente et incompatible.

L'histoire d'Eric Allman de Sendmail, Inc. est similaire : il avait pensé former un consortium, mais toutes les portes se sont fermées devant lui. Pour garder le contrôle, il a donc quitté son emploi et fondé Sendmail avec Greg Olson. Il promet qu'une version gratuite restera disponible, mais semble vouloir vendre des licences aux grands constructeurs informatiques.

Même si les histoires de chacun diffèrent, il existe un point commun : tous travaillent sur un modèle rentable qui permettrait de payer les développeurs et une organisation de support technique, sans abandonner les avantages des logiciels open source. Comme le montre l'exemple de la diffusion des sources de Mozilla par Netscape, cette idée attire même l'attention de distributeurs de logiciels propriétaires traditionnels.

7.3 Freeware, open source ou sourceware ?

Nous avons passé un certain temps à discuter de la terminologie à adopter. Tim organisa un sondage d'opinion parmi nous. Free software et freeware ont reçu très peu de votes positifs (freed software eut même beaucoup de votes négatifs). À l'arrivée, on constata une égalité entre open source software (le favori d'Eric Raymond) et sourceware (qui a déjà été utilisé par Cygnus).

J'avais personnellement des réticences sur open source, mais je le préfère au trop mignon sourceware, et je suis d'accord pour dire que freeware a une mauvaise réputation  en plus du fait que la plupart des logiciels freeware ne sont pas livrés avec leurs sources, alors que le point commun de tous les logiciels représentés à ce sommet est la disponibilité du code source.

Eric Raymond a déposé l'appellation Open Source (avec les majuscules), et a une définition très précise de ce qui est Open Source et de ce qui ne l'est pas, sur son site Web (voir ci-dessous). Je m'inquiète parfois de ce que cela puisse être une limitation : que se passera-t-il si j'appelle mon logiciel Open Source (avec son approbation), et que je change par la suite les termes et les conditions de distribution, ou si Eric change sa définition ? Je pourrais être poursuivi par quelqu'un qui me dirait que je dois me conformer aux règles Open Source. Eric ne croit pas que ceci va se produire, et ajoute que tout le monde est libre d'utiliser l'appellation open source (sans majuscules) sans coller à sa définition. Nous verrons bien. Pour l'instant, je suis favorable au concept, mais nous ne mettrons pas Open Source sur le site de Python dans l'immédiat (nous ne mettrons pas freeware non plus.)

7.4 Et après ?

Nous avons brièvement discuté de l'approche à adopter envers la presse et les possibles prochaines rencontres. La conclusion générale semble être que le temps est venu pour nous d'essayer de faire passer le message au niveau supérieur des managers dans des entreprises qui utilisent déjà des produits open source  les DG qui ne savent même pas que leurs propres développeurs utilisent Perl ou Python, et qui n'écoutent que leurs collègues DG, le Wall Street Journal, et les (ruineuses) entreprises de consulting et d'analyse de marché, qui n'ont toujours pas découvert le logiciel open source non plus. Comment allons-nous faire ? La conférence de presse est déjà un pas fait dans la bonne direction, et O'Reilly s'occupe de faire suivre auprès de la presse. Eric Raymond discute beaucoup avec des gens de la société corporatiste. Sarah Daniels, de Scriptics, a eu de bonnes idées pour une campagne de publicité commune (nous verrons cela...).

Qu'ai-je retiré de tout cela ? Beaucoup. Une clarification des raisons pour lesquelles le logiciel open source fonctionne si bien, comment le faire marcher encore mieux, et aussi la motivation de trouver une manière de le rentabiliser.

7.5 La conférence de presse

La conférence de presse a commencé à 17 h 30, et a duré jusqu'à 19 h 30 ou 20 h. Tous les développeurs se sont assis derrière une longue table avec des petits chevalets portant leurs noms, avec Tim O'Reilly en milieu de table. Il y avait environ 20 ou 30 journalistes. Pendant la première heure, on nous prenait en photo au rythme de deux photos par seconde. Tim O'Reilly fit une brève introduction, puis laissa faire la presse. Celle-ci s'attacha plus aux noms les plus connus, je n'ai donc pas eu grand-chose à dire (il va sans dire que ce n'est pas le cas des deux types de chez Netscape).

Comme il était prévisible, nous avons parfois eu du mal à ne pas rester toujours dans les questions du genre « comment comptez-vous éliminer Microsoft ? » et les remarques du style « il est évident que cela ne peut pas marcher ». Il y a des journalistes auxquels vous pouvez répondre le plus clairement du monde et qui se contenteront de vous regarder dans le blanc des yeux d'un regard vide, et de vous reposer la même question formulée en des termes à peine différents. Mais la plupart essayaient réellement de comprendre le message (certains même l'avaient déjà compris avant de venir). Une fois que cette partie formelle de la conférence de presse fut finie, nous nous sommes dispersés dans la salle, et le reste du temps s'est passé en entrevues en petits groupes d'un ou deux journalistes et un ou deux développeurs.

L'un dans l'autre, ce fut un événement intéressant et utile  vous pouvez en voir les premiers résultats ci-dessous. Bien sûr, nous devrons voir si nous changerons réellement la perception du modèle de développement open source, actuellement considéré comme un phénomène marginal.

7.6 Références

(Celles-ci sont antérieures au sommet.)

7.7 Revue de presse

(Aimablement fournie par le service de relations publiques d'O'Reilly.)

Pour plus d'informations sur ce sujet, voir webreview.

Copyright (c) 1998 Guido van Rossum -- Publié dans le n°28 de la Linux Gazette.

Adaptation française : Roland Mas.

Précédent Suivant Table des Matières