FreeBSD, Etat de l'union, 1999
De Jordan Hubbard <jkh@FreeBSD.ORG>, dimanche 10 janvier 1999.
Et bien les amis, une nouvelle année vient de s'écouler et il est certainement grand temps de faire une mise au point sur l'état de notre union !
Hum... Je ne sais pas très bien comment aborder la chose car à chaque fois, je me rappelle un certain président des Etats-Unis, assis devant la cheminée, essayant d'avoir l'air chaleureux et populaire, faire un état de la croissance du maïs ou bien peut-être la Reine d'Angleterre à noël donnant son habituelle allocution sombre-mais-optimiste sur ce qu'il est advenu de la Grande-Bretagne pendant l'année et sur ce que chacun peut espérer de la suivante. Ces descriptions ne me ressemblent pas vraiment aussi vais-je couper court et m'intéresser aux leçons plus pertinentes (et objectives) que j'ai retenu pour l'année 1998.
1998 a été, bien sûr, l'année de forte croissance d'internet (pas de surprise), divers "internetpraneurs" (gag) se sont enrichis et la base des utilisateurs de FreeBSD, d'après les statistiques de téléchargement ftp, a augmenté à son rythme habituel de 200 à 300 %. D'autres entreprises sont entrées dans l'arène FreeBSD pour apporter soit des add-ons soit des solutions à base de FreeBSD et notre machine à relations publiques (RP), toujours aussi légère et discrète, continue d'ouvrir de nouvelles brèches. Finalement, c'était une très bonne année pour FreeBSD et même le plus paranoïaque d'entre nous ne pense pas autrement - Microsoft s'en est pris plein la poire, nous avons progressé et sommes devenus un peu plus connus, la vie était belle.
Bon, je quitte mes lunettes roses pendant une seconde et je peux aussi dire qu'il reste encore pas mal de cailloux sur la route et que certains travers inattendus ne nous ont pas toujours laissé le contrôle de la situation. Alors que les téléchargements se font de plus en plus nombreux, les ventes de cédéroms n'en font pas autant, leur marché en général souffrant de la démocratisation d'internet et leurs avantages fondamentaux s'érodant. Nous avons quand même poursuivi, considérant l'implosion progressive du marché, mais il serait idiot de continuer à compter uniquement sur le seul cédérom pour fournir les ressources qui ont solidement huilé les rouages du projet (nous avons, par exemple, plus que doublé la taille du cluster informatique de FreeBSD.org et significativement élargi en 1998 notre programme de donations d'équipements pour les développeurs, toutes sortes de choses qui coûtent de l'argent). Il est assez évident que Walnut Creek CDROM devra augmenter l'offre de ses produits s'il veut rester un acteur important dans le secteur de FreeBSD et nous devons garder, en tant que projet, notre flexibilité dans la recherche de relations avec des gens qui auraient des intérêts dans le succès de FreeBSD. Le temps est passé où, comme solution sérieuse et "qui monte", nous pouvions faire ce qu'il y avait à faire en comptant uniquement sur les bonnes volontés et les bénévoles isolés.
Dans cet esprit, des sites comme La boutique FreeBSD ont été mis en place afin de proposer des produits en relation avec FreeBSD et nous avons commencé à explorer des partenariats avec diverses entreprises qui pourraient tirer profits des campagnes de relations publiques qui améliorent la réputation de FreeBSD (traduction : il faut qu'elles aident à payer :). Comme beaucoup de personnes l'ont précisé amèrement, ce commerce est devenu une équation à 10% de technologie et 90% de sensibilité pour ce qui concerne la direction dans laquelle les gens se ruent, et n'aiment pas cette foule de petits moutons sans cervelles, mais vous devez malgré tout comprendre leurs tendances et leurs comportements lorsqu'il s'agit de choses qu'ils ne comprennent pas vraiment. Nous avons fait du beau boulot technologiquement, vraiment (et nous pouvons en être fiers), mais nous avons trop souvent laissé tomber le problème de la sensibilité et demandé aux gens de penser ce qu'ils voulaient. Mauvais techies ! Myopes techies ! :-)
Que faire pour que cela change en 1999 ? Et bien, j'ai aussi entendu notre équipe d'évangélistes réclamer du support logistique ("Des renforts ! Nous avons besoin de renforts ici !) et je l'ai écouté, une partie de mon projet pour les années à venir étant d'avoir plus d'images de démons disponibles (ce que j'ai déja commandé), d'avantage de revues avec diverses comparaisons ("FreeBSD et NT", "FreeBSD et Solaris", "FreeBSD et Linux", etc) et plus de bulletins d'informations pour le public. Nous pouvons aussi produire plus de produits marketing comme des boutons, des autocollants, de nouveaux tee-shirts, etc... pour donner aux gens un plus large choix de produits leur permettant de montrer fièrement qu'ils supportent le "phénomène naissant FreeBSD". Si nous parvenons à disposer de plus d'argent pour les relations publiques, peut-être pourrons-nous aussi acheter certains éléments en vrac afin de les utiliser comme cadeaux dans diverses actions promotionnelles. A part ça, je suis toujours ouvert aux suggestions. Nous avons besoin de faire plus de relations publiques efficaces, c'est indiscutable, il nous faut seulement choisir nos cibles pour un maximum d'effet avec un budget limité.
L'équipe de direction ("core team") :
1998 a aussi fini avec quelques coups en ce qui concerne la direction du projet FreeBSD, une frustration avec une équipe de direction presque gisante encourageant un couple de vikings danois barbus dans un raid de minuit sur la version -current, massacrant impitoyablement le code source faible ou boiteux de la hiérarchie des sources. Malheureusement certains bits de ces codes faibles ou boiteux étaient encore utilisés et, sans qu'aucun avertissement n'ait été donné, cela n'a pas laissé le sentiment aux utilisateurs de la -current que cet évènement serait le point culminant de leur saison de noël. Leurs plaintes ont amenées l'équipe dirigeante non loin d'une crise constitutionnelle, les factions rivales s'accusant l'une l'autre soit de gêner le progrès soit d'employer des tactiques de cowboys pour parvenir à ce progrès, et chacune des factions avaient leurs torts et leurs raisons. Il ressortit de cette histoire plusieurs suggestions concernant la mise en place d'une "meilleure équipe de direction" à laquelle de telles choses n'arriveraient pas (ou, si elles arrivaient, ne serait pas de notre faute puisque nous serions partis depuis longtemps :-). Plusieurs des remèdes suggérés se sont révélés, tout à fait honnètement, être pire que le mal. Quelle leçon en avons-nous donc tiré ?
Premièrement, je pense que tout le monde est d'accord pour trouver que se chamailler n'est pas une option à retenir pour le futur, quelque soit la justification. Quiconque veut faire un ajout majeur ou veut supprimer une fonctionnalité à la hiérarchie des sources DOIT communiquer ses intentions suffisamment à l'avance et donner aux lecteurs des listes -current, -stable ou -announce (les deux premières dépendant de la version sur laquelle les changements sont effectués, le dernier dépendant de l'ampleur de ceux-ci) un temps suffisant pour répondre. S'il y a une réponse négative, le changement ne doit pas s'opérer à moins qu'à force d'arguments en sa faveur, la proposition ne gagne l'approbation des gens. S'il y a un ensemble de réactions contradictoires ou s'il n'y a qu'une petite réaction, le développeur est libre de faire comme il l'entend mais jamais sans avis préalable.
Deuxièmement, en réaction aux diverses propositions de réduire l'équipe dirigeante ou de l'élire par voix populaire, laissez-moi vous dire que nous n'allons pas faire cela. Il y a probablement plusieurs personnes actuellement dans l'équipe dirigeante qui seraient heureuses de se retirer si elles sentaient que la relève était assurée et que le projet serait en de bonnes mains mais personne n'apprécie le scénario où quelqu'un serait forcé à quitter l'équipe dirigeante. Ce n'est pas la bonne façon d'y arriver alors que d'autres solutions moins douloureuses existent et je préfère largement agrandir l'équipe dirigeante et laisser les membres inactifs sortir quand ils ont pris, eux-même, la décision qu'ils n'avaient plus rien à apporter au "niveau de direction", la démission n'ayant pas empèché plusieurs personnes de rester des participants efficaces ou d'apporter d'autres contributions apréciables.
Nous sommes un projet de logiciel libre et personne n'est payé pour faire partie de l'équipe dirigeante, quelque soit le sérieux avec lequel nous le prenons et nous devons nous rappeler que tout ceci a commencé par un groupe de gens qui voulait simplement travailler ensemble à créer quelque chose d'utile et d'intéressant. Le jour où nous perdrons cette atmosphère informelle de productivité pour cause de politique sera le jour où une chose fondamentale aura disparu de l'équipe dirigeante et aussi le jour où je partirai moi-même, en laissant mon poste à un remplaçant et en souhaitant à tout le monde bonne chance.
Je peux aussi donner un avertissement similaire en ce qui concerne l'idée d'élire l'équipe dirigeante à partir des utilisateurs ou des principaux participants qui joueraient le rôle de "collège électoral", aussi belle et démocratique que cette idée puisse avoir l'air. L'équipe dirigeante de FreeBSD ne représente pas un corps démocratiquement choisi mais a été, en fait, soigneusement constituée de manière très non-démocratique. Nous avons sélectionné ses membres avec l'intention spécifique qu'elle représente un ensemble aussi varié que possible d'évangélistes et de développeurs FreeBSD convaincus et nous avons continué à accepter d'autres personnes selon les mêmes critères.
Pour introduire une personne dans l'équipe dirigeante, nous ne regardons pas si elle a récemment gagné des concours de popularité ou gagné l'Oympiade de Programmation trois fois de suite, nous nous demandons : "Cette personne apportera-t-elle un talent ou un point de vue unique au groupe ? Le groupe fera-t-il mieux que la somme de ses membres ?" Ce sont nos deux principaux soucis et, en fait, les seules raisons pour lesquelles nous avons senti qu'il était nécessaire de demander à quelqu'un de démissionner de l'équipe dirigeante. Nous pouvons nous permettre d'être tolérant envers une personne mais pas lorsque cela affecte les conditions de travail de l'ensemble du groupe ou que cela mine la diversité d'opinion que nous avons durement cultivée. Il est agréable d'être un groupe efficace de décideurs en tant qu'équipe dirigeante et nous avons nos moments importants (bons et mauvais) mais il est parfois préférable de savoir se tenir à l'écart et de simplement s'assurer que le train reste sur ses rails. Nous avons évité pas mal d'idioties grace à cette équipe diversifiée et soigneusement choisie et je ne pense pas qu'un processus démocratique nous aurait permis le même résultat.
L'équipe dirigeante continue aussi son travail de documentation interne qui décrit, de la façon la plus détaillée possible, ce que sont nos règles en tant que participants, celles supplantant les "privilèges des membres de l'équipe dirigeante", celles régissant les ajouts ou retraits importants de code source. Nous enverrons quelque chose aux participants dès que nous en seront satisfait mais, en un mot, cela insistera sur le fait que les gens ont besoin d'être avertis avant de tels changements et que le responsable d'une branche de code est prioritaire pour dire s'il est temps ou pas de l'enlever pour cause d'obsolescence ou de redondance. Enfin, nous nous penchons sur la communication interne et externe à l'équipe dirigeante ainsi que sur la question d'inclure de nouveaux membre(s) dès maintenant. Cette discussion est en cours et je ferai de mon mieux pour tenir tout le monde au courant de sa progression.
Numérotation des versions :
D'autres décisions à venir concernent le retour à notre ancienne pratique d'utiliser des numéros de version "majeurs" pour les branches et des numéros "mineurs" pour les versions, la partie pour le numéro de révision n'étant utilisée que pour noter des versions intermédiaires sorties pour des raisons suffisamment importantes pour mériter une nouvelle version. Cela veut dire que la prochaine version sera la 3.1 et non la 3.0.1 et que la nouvelle branche sera la 4.0-current au lieu de la 3.1-current. Est-ce juste une stratégie marketing ? Non, bien que cela eut, en effet, de fréquentes incidences sur notre système de numérotation.
Nous avons fréquemment dû faire d'importants changements entre nos "versions intermédiaires", des sauts comme 2.2.5->2.2.6 et 2.2.6->2.2.7 étant beaucoup plus importants que ce que peuvent penser la plupart des gens en se basant sur le fait que seul un petit numéro de version a changé. Cette simple facette de la nature humaine a réduit l'impact de ces versions et fait sous-estimer le travail réalisé par nos développeurs pour améliorer fortement chaque version, indépendamment de la branche de développement.
Ce n'est pas une tendance qui semble réversible et je me sens en droit de dire que la 3.1 sera une "version complète" après la 3.0 alors qu'une "3.0.1" aurait donné une autre impression. Il est également important de noter que, puisque nos branches restent typiquement 12 à 18 mois en ce moment, ce n'est pas grave que nous en détruisions une plus tôt, un saut à une version majeure (4.0) étant entièrement mérité pour quelque chose qui ne sortira pas avant l'an 2000. L'équipe marketing sera contente car elle ne bataillera plus pour comprendre les numéros de versions et les utilisateurs seront contents car ils auront une meilleure image de ce qui a changé avec, par exemple, 3.1 à 3.2 au lieu de 3.1 à 3.1.1 (qui peut être une mise à jour importante concernant la sécurité). Le développeur sera aussi content puisque j'aurai un numéro de révision à nouveau disponible pour les versions intermédiaires. C'est une victoire et nous l'assumerons. La 3.0.1 est morte, longue vie à la 3.1 ! :)
Technologie:
L'année passée a aussi vu la transition réussie du format a.out au format ELF ainsi qu'un nouveau noyau avec modules à chargement dynamique qui permet aux modules d'être chargés sans dépendre d'un runtime dans /usr/bin/ld. Nous avons aussi un nouveau gestionnaire de démarrage (avec interpréteur forth !) pour assembler un "noyau" au démarrage. Ce sont deux nouveaux puissants mécanismes et couplés avec les fonctions à venir en 1999, ils devraient nous donner un système bien plus dynamique et extensible que nous n'avons jamais eu.
A ne pas oublier aussi, notre nouveau système SCSI CAM qui a un comportement plus stable avec les gros disques et qui supporte plus de contrôleurs SCSI ou le support du multi-processeurs sur plate-forme x86. Nous avons énormément progressé sur toute la ligne avec la version 3.0, atteignant finalement un point avec le portage vers l'architecture DEC Alpha où les gens commencent à s'inquiéter d'avantage à propos de la collection de logiciels portés que sur le fait d'avoir des noyaux fonctionnels ou un /usr/src qui compile. Cela représente un progrès considérable vers une "utilité véritable" et j'espère que 1999 verra l'avènement d'une version de FreeBSD/axp pour une utilisation personnelle (sans parler d'une version pour les serveurs), certaines difficultés avec le serveur X faisant de la version Alpha pour une utilisation personnelle une étape en elle-même, surtout sur les machines ARC ou AlphaBIOS. 1999 devrait aussi voir la sortie d'une version pré-alpha du portage sur SPARC, bien qu'il soit encore un peu tôt pour en parler plus précisément. Abonnez-vous à la liste de diffusion sparc@FreeBSD.org pour suivre les progrès de ce portage.
IPv6 et IPSec ont également été chaudement débattus en 1998, le refus de FreeBSD de soutenir une quelconque implémentation spécifique étant cité par certains comme un exemple du sur-conservatisme de l'équipe dirigeante. Heureusement pour tous, notre attitude "attendre et regarder" a prouvé être la bonne lorsque les deux groupes "en compétition", KAME et INRIA, ont finalement décidé de fusionner leurs implémentations. Nous avons, en retour, décidé d'adopter cette implémentation commune et nous avons plusieurs personnes des groupes KAME/INRIA dans l'équipe de développement FreeBSD qui importeront et maintiendront ce code dès qu'il sera disponible.
Un travail substantiel est parallèlement effectué sur le code de la mémoire virtuelle et sur le code du système de fichiers, la plupart tranquillement testé par de petits groupes (Dillon/Dyson/Greenman) ou attendant l'avènement de la branche 4.0, toujours programmée pour le 15 janvier 1999. Dans un autre domaine, nous avons acceuilli la refonte totale du pilote de console de Kazu dans la -current ainsi que le support USB grâce à Nick Hibma et d'autres. Tout ceci pour prendre quelques exemples parmi tous les projets en cours, je ne veux offenser personne en n'en nommant pas d'autres, ce sont uniquement les trois projets qui me viennent à l'esprit. Il semble que nous gagnions beaucoup d'élan technique, c'est très bien, et nous continuerons tant que nous garderons la tête froide pendant les périodes où tout le monde ne sera pas en accord total à propos de la direction technique à prendre.
Support technique :
Un point qui devrait aussi être évident pour tout le monde mais qui a quand même besoin d'être rappelé fréquemment est le fait que la participation à ce projet doit rester agréable pour les développeurs et participants ou bien ceux-ci auront vite fait de repartir et d'arrêter de nous donner le fruit de leur labeur (qui n'a pas de prix). C'est une chose dont chacun de nos utilisateurs doit être conscient, au moins quelque part dans un coin de leur esprit, pour les fois où ils seraient tentés de penser que FreeBSD n'est qu'une autre solution de la société Logiciels & Co et commencent à traiter les membres du projet comme des employés. Ceux qui cherchent des employés FreeBSD peuvent envoyer un courriel à jobs@FreeBSD.org en indiquant combien ils sont prêts à payer, sinon, ne le faites pas.
Je ne voudrais pas me montrer si sévère que les gens ne prennent même plus la peine de nous demander de l'aide, je veux simplement dire que les gens qui utilisent eux-mêmes les divers moyens gratuits de support technique de FreeBSD (courriel, forums, irc...) doivent comprendre que demander de l'aide à un parfait étranger n'est pas très différent que demander un dollar à une personne au hasard dans la rue. Si vous voulez une aumône, il vous faut au moins apprendre à demander poliment et savoir prendre un "non" comme une réponse ! :-) J'ai vu énormément d'abus envers les volontaires des divers supports techniques cette année et ça "craint" franchement. Les gens doivent avoir plus de considération et arrêter de prendre ce service gratuit comme un droit divin alors que c'est un privilège spécial. Si vous voulez du support technique à la demande, allez sur www.freebsdmall.com et commandez vous-même votre contrat de support technique. Vous obtenez ce que vous payez ! :)
L'avenir :
Qu'est-ce que je prévois pour 1999 ? Et bien, à supposer que nous ne disparaissions pas tous dans quelque holocaust pré-millénaire, je vois de nouvelles fonctionnalités plus intéressantes, un marketing amélioré, plus d'articles commerciaux, plus d'articles dans les magazines et d'attention de la part de la presse, et, au fond, davantage que ce que nous avons déjà si nous pouvons raisonnablement nous focaliser sur ce que nous avons à faire et ne pas nous distraire dans la chasse au rêve de la conquête des machines personnelles ou devenir subitement minimaliste ou encore se cloîtrer dans la cuisine /usr/src, continuant ainsi ce pour quoi nous sommes en partie célèbre. L'équipe dirigeante de FreeBSD, d'une année plus vieille et espérons le un peu plus sage, doit continuer à garder une main légère mais assurée sur la barre, s'appuyant comme d'habitude sur nos développeurs pour fournir la plus grande partie de la force motrice de FreeBSD.
Nos utilisateurs ont aussi besoin d'être plus impliqués et j'espère que 1999 sera l'année de formation de plus de groupes locaux ainsi que d'autres organisations. Le manuel de référence et la FAQ sont des documents qui s'améliorent, une autre tendance qui si tout va bien continuera en 1999 si Nik Clayton, notre nouveau courageux dirigeant du Projet de Documentation, reste aux commandes. Nous devons cependant toujours nous rappeler que le manuel de référence et la FAQ, pour beaucoup d'utilisateurs, ne suffisent pas.
Linux a beaucoup de succès grâce à un large réseau de support et d'évangélisation qui lui a permis d'atteindre telle personne et de leur communiquer le message. Si les propres utilisateurs de FreeBSD veulent que FreeBSD fasse mieux que celui qui est souvent perçu comme son concurrent, et 1998 a certainement été l'année où j'ai entendu beacoup de plaintes sur ce sujet, alors il faut qu'ils bougent leurs fesses collectives et qu'ils se mettent à ce genre de travail. A quand remonte la dernière fois qu'un groupe d'utilisateurs FreeBSD s'est regroupé pour distribuer la littérature FreeBSD lors du lancement d'un produit Microsof, par exemple, ou s'est occupé d'un installa-thon à un salon informatique local ?
Les linuxiens font cela tout le temps apparemment, pendant qu'une poignée d'inconditionnels de FreeBSD le font, alors rejoignez la liste de diffusion advocacy@FreeBSD.org et discutez de vos plans d'actions. De cette façon, des gens qui ont plus d'entousiasme que d'idées penvent en tirer des leçons et peuvent peut-être vous aider. Ecrivez de courts articles pour les nouveaux site d'évangélisation comme www.daemonnews.org ou www.freebsdrocks.com et aidez à promouvoir le succès des publications d'évangélisation BSD.
Des phrases comme "c'est votre FreeBSD" et "cela dépend de vous" peuvent sembler éculées et banales mais elles restent malheureusement toujours vraies quand il y a si peu de "nous" et tant de "vous". Si FreeBSD poursuit vraiment son succès en 1999, ce sera seulement grâce à la substantielle participation des utilisateurs, c'est à dire de vous, utilisateurs ! Créez votre groupe local, donnez quelques-uns de vos vieux cédéroms d'installation à votre bibliothèque locale, essayez de convaincre une petite entreprise locale ou un FAI d'utiliser FreeBSD, voilà quelques petites choses qui peuvent être faites si vous voulez vraiment mettre de l'énergie dans FreeBSD et les idées doivent être le dernier de vos soucis si vous êtes motivés.
Résumé rapide : 1999, rah rah rah, au boulot ! :)