FreeBSD, Etat de l'union, 1999
De Jordan Hubbard <[email protected]>, 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 [email protected] 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 � [email protected] 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 [email protected] 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 ! :)