Ces dernières années, un grand nombre d'individus ont réclamé une sorte d'organisation ``centrale'' pour Linux.
Les raisons invoquées ont été :
Il faut empêcher quiconque de s'approprier, pour les rendre privés, des objets versés dans le ``domaine public''.
Les sociétés ont besoin d'une assistance technique plus officielle que : Allez poser vos questions sur l'Internet. Elles veulent un système organisé de telle sorte que les utilisateurs ayant des problèmes puissent appeler une sorte de service ``S.O.S.''. Ceci pourrait inclure une assistance téléphonique aussi bien que des consultations plus officielles.
Cela dit, InfoWorld a récemment attribué à "la communauté Linux sur Internet" leur prix InfoWorld Best Technical Support (Prix InfoWorld de la meilleure assistance technique).
Il n'existe pas de consensus quant au type d'organisation qui devrait être ``reine'', néanmoins, il existe un désir de reine...
L'assistance technique proposée aux utilisateurs de Linux n'est pas à mon avis parfaite, mais cela n'implique pas la création d'une organisation centralisée qui fasse autorité.
Je dirais même que le modèle de décentralisation promu par Linux représente une force dans le sens où il permet à l'assistance technique de s'améliorer simultanément dans différentes parties du monde, sans en être empêchée par telle ou telle agence de contrôle.
Il y a des inconvénients à ce modèle décentralisé du développement Linux, car il provoque une fragmentation des sources d'aide disponibles. Linux n'a pas d'organisation unique fournissant toutes les choses listées ci-dessous, comme c'est le cas pour la plupart des autres systèmes d'exploitation. Les différentes spécialités concernant les activités connexes à Linux sont donc réparties entre plusieurs organisations de la communauté Linux :
C'est un problème insoluble étant donnée la diversité des acteurs impliqués, qui va également de pair avec une grande diversité des besoins.
Ceci concerne les noyaux de la série 1.2.x, qui ont été stables pendant longtemps, jusqu'au point de devenir anciens, mais aussi les noyaux 2.0.x, plus modernes, mais qui évoluent vite, et les séries expérimentales 2.1.x qui changent pratiquement toutes les semaines.
De plus, il y a eu plusieurs bibliothèques C (avec la récente
transition de la libc 5.x (bibliothèque standard du langage C,
version 5 à la ``GLIBC'' GNU (bibliothèque standard du langage C de
GNU
NdT Gnu's Not Unix, est une fondation qui a pour
projet de développer le logiciel libre (c'est-à-dire couvert par une
licence mise au point par elle, la GPL) et en particulier de créer un
système Unix complet libre
)), plusieurs formats
d'exécutables (avec la transition du format a.out au format ELF
format reliable ainsi qu'exécutable), et enfin, trois compilateurs
C/C++ qui se marchent plus ou moins les uns sur les autres (GCC
(compilateur de C de GNU) 2.7.x, GCC 2.8.x, EGCS (système de
compilation expérimental de GNU)). Les transitions entre les
différentes versions de bibliothèques ont parfois été douloureuses.
Les détracteurs de Linux exagèrent souvent ces problèmes. La plupart des programmes n'ont pas besoin d'avoir connaissance des différences entre ces différentes composantes du système, et la plupart du temps, ils n'ont même pas besoin d'être recompilés afin de pouvoir fonctionner sur un système utilisant un nouveau noyau ou de nouvelles bibliothèques.
Il peut encore être délicat pour les développeurs de sélectionner un noyau cible approprié ou une bibliothèque particulière, surtout quand des fonctions spécialisées ou encore au stade expérimental comme le verrouillage de ressource, le ``multithreading'', ou la programmation multi-processeurs, sont requis.
Il existe un grand nombre de bibliothèques graphiques fonctionnant sous Linux, dont Xt, Motif, Tk, Qt, Gtk et GNUStep, pour ne citer que les plus populaires. Ce problème n'est bien sûr pas spécifique à Linux. Il est à peu près identique pour des applications tournant sur les autres systèmes d'exploitation de type UNIX.
Ce problème concerne également les autres plates-formes non apparentées à UNIX. Les systèmes MS-Windows proposent également un grand nombre d'APIs (interfaces de programmation pour applications) et de bibliothèques issues d'une multitude de sociétés.
Malgré les quelques inconvénients dus à la décentralisation, je crois que c'est un avantage décisif pour Linux d'être soutenu par une multitude d'organisations indépendantes jouant des rôles variés. On peut voir toutes ces parties comme un agrégat constituant une sorte de ``corporation virtuelle''.
Tant que ces diverses organisations restent légalement et vraiment indépendantes, Linux n'aura pas à affronter le genre de problèmes qui ont assailli IBM et Apple.
Apple a des problèmes liés à la question ``matériel ou logiciel ?''.
Apple s'est récemment posé la question de savoir s'il était plutôt un vendeur de matériel ou de logiciel.
Parmi les sociétés qui ont copié leur exemple, plusieurs ont eu le même dilemme. Il y eut tout d'abord NeXT, qui a commencé par vendre un ordinateur à l'air sympathique en forme de ``monolithe noir'', mais qui a ensuite conclu qu'il valait mieux se concentrer sur le développement de leur logiciels d'interface graphique pour utilisateur (GUI).
Plus récemment, d'anciens employés d'Apple ont fondé la société Be, et ont mis au point une jolie machine PowerPC SMP (à multi-processeurs symétriques) sur laquelle fonctionnait un système d'exploitation sympathique, conforme à la norme POSIX, et capable de gérer les processus légers. De même que les gens de NeXT, ils ont conclu qu'il valait mieux se focaliser sur l'amélioration et la commercialisation de BeOS, leur système d'exploitation.
Cela faisait longtemps qu'Apple vendait du matériel, et elle en avait tiré beaucoup d'argent. C'est pourquoi elle demeure dans un état d'indécision continue, qui a fait naître une certaine confusion récemment quand ils ont acheté NeXT et annoncé Rhapsody, adhérant ainsi, d'une certaine manière, à l'idée selon laquelle ``le logiciel est roi''... pour peu après acheter Power Computing (un vendeur de clones de Mac), portant là un coup fatal aux vendeurs de clones et rejoignant ainsi, d'une certaine manière, ceux qui estiment que ``le matériel est roi''.
Nombreux sont ceux qui pensent qu'ils faudrait s'éloigner du marché du matériel et devenir avant tout un vendeur de logiciels, y compris à l'intérieur d'Apple. Mais les succès passés de cette société en tant que constructeur de matériel est sans doute un obstacle à cette idée.
Ses activités liées au logiciel pourraient être bien meilleures si elles n'avaient pas à se soucier de la santé de la composante matérielle, et vice versa. Et cela pourrait faire du bien à l'ensemble de l'organisation.
IBM s'est souvent fait remarquer pour dépenser des millions de dollars en développant de nouveaux produits, puis en les abandonnant avant même d'essayer de les mettre sur le marché. Et ceci dès l'instant où une autre division a pensé que le nouveau produit cannibaliserait ses propres ventes.
IBM : Ne cannibalisez pas mon marché !
IBM est une société qui illustre fort bien l'idée d'abandonner de bons produits pour éviter de défavoriser les ventes d'autres produits. C'est, bien sûr, une conséquence directe du fait qu'IBM est si grande qu'il est difficile de trouver un nouveau produit qu'elle pourrait ajouter à son catalogue sans réduire ne serait-ce qu'un peu les ventes d'un autre produit.
Malheureusement, quand un tel problème est combiné avec une société absolument énorme, ce qui suppose une grosse bureaucratie sous-jacente, et de nombreux cadres puissants susceptibles de s'affronter, les considérations techniques sont reléguées au second plan, derrière les considérations politiques.
OS/2 en est un bon exemple :
Essayer de soutenir OS/2 au sein même de la compagnie était un problème ; il y avait plusieurs raisons à cela et les autres divisions d'IBM étaient activement opposées à l'utilisation d'OS/2. Il y a sans aucun doute des périodes pendant lesquelles les ventes liées à UNIX mettent en danger les ventes de serveurs (de calculs), ce qui pose la question de savoir quel ``danger'' préférer. OS/2 n'a évidemment pas reçu le soutien nécessaire pour combattre les systèmes Microsoft.
La Free Software Foundation a eu le problème d'avoir un leader, Richard M. Stallman (ou ``RMS'') qui a tendance à penser qu'elle devait avoir le contrôle sur le contenu du logiciel libre (sous licence GPL : GNU Public License, licence publique générale de GNU). Sans même avoir pu prendre en considération le fait que les autres pouvaient ne pas vouloir se laisser contrôler, ils n'ont simplement pas eu assez de moyens pour gérer tous les projets en cours...
Le logiciel libre représente potentiellement un million de dollars d'efforts par an. La Free Software Foundation n'est certainement pas assez développée pour gérer les résultats issus d'une telle activité. Et je ne suis pas certain qu'elle puisse croître suffisamment pour démentir cela.
Les programmeurs de Linux n'ont personne pour les empêcher d'introduire une nouveauté. Personne ne demande la permission à Linus Torvalds pour quoi que ce soit...
De plus, les développeurs Linux utilisent typiquement des protocoles standardisés qui permettent aux projets de se développer indépendamment, ce qui signifie que l'on est rarement obligé d'attendre une ressource particulière. Par exemple, le protocole X11 utilisé pour implanter le système X Window ( X Window System) est un standard graphique stable. Le développement peut donc s'appuyer indépendamment sur des entités comme les serveurs X, les bibliothèques graphiques (GUI), le noyau Linux et d'autres composants système.
Par opposition, les évolutions du système MS-Windows sont souvent douloureuses car les composantes du système et les applications sont profondément entremêlées. Ceci profite aux sociétés de services de tout poil qui ont à régler les dysfonctionnements, mais c'est extrêmement nuisible à la communauté qui doit subir ce genre d'évolution.
Les systèmes de type UNIX et les systèmes de type Microsoft contrastent techniquement dans cette optique :
Ceci a pour conséquence malheureuse que si l'un des composants du système est modifié, tous les logiciels doivent être modifiés en conséquence.
Sur les systèmes UNIX, la mise à jour d'un composant n'a en principe aucun effet néfaste sur les programmes. Il existe des contre-exemples, mais ce sont plutôt des exceptions que la règle...
Les mises à jour du noyau Linux n'affectent directement le fonctionnement que d'une très petite partie des programmes.
Les mises à jour de X Window de la version X11R4 à la X11R5 puis à la X11R6 n'ont pas occasionné de dysfonctionnements significatifs pour les programmes écrits pour des versions antérieures. Il peut y avoir des avantages à en réécrire certaines parties pour utiliser des fonctionnalités des nouvelles bibliothèques, mais ce n'est pas nécessaire. Il n'est même pas nécessaire de recompiler les programmes, comme si leur environnement n'avait pas changé.
En outre, faire fonctionner des programmes utilisant la nouvelle bibliothèque graphique Gtk n'empêche pas les applications programmées sur Xt de fonctionner. Ceci témoigne de la capacité de X Window System à faire cohabiter différentes interfaces graphiques utilisateur.
La période pendant laquelle Della Croce a revendiqué la propriété de la marque ``Linux'' a montré l'importance de ce dernier point. Il a eu pendant quelque temps le contrôle légal sur le nom, ce qui a provoqué une grande émotion dans la communauté Linux. Une pétition d'annulation a circulé contre cette marque Linux. Le cas a été jugé par une cour de justice ; Linus Torvalds est maintenant propriétaire de cette marque.
Par contraste, depuis que Linus a accepté le fait que Linux utilise la General Public License, personne, d'un point de vue légal, n'a eu ou n'aura de contrôle unique sur le code source de Linux. Pour que ce code soit privatisé légalement, des milliers de contributeurs à Linux devraient donner leur accord. Il en existe suffisamment qui ne seraient certainement pas d'accord pour que cela ait peu de chance d'arriver.
Si Linux reste fragmenté de la sorte dans son assistance technique, cela signifie qu'il peut y avoir des problèmes qui passent à travers les mailles du filet, et cela est dommageable.
Le projet NetBSD, qui consistait à construire un système gratuit à partir de ``BSD 4.4 Lite'', semble s'être fracturé à cause de désaccords internes, ce qui a provoqué une scission vers le projet OpenBSD. Il est difficile (sans rentrer dans la grande controverse) d'en établir les causes précises. Mais ces causes mises à part, la séparation a jeté le trouble sur la crédibilité des deux parties.
En n'étant pas organisées de façon monolithique, les personnes impliquées dans Linux sont libres de travailler de manière aussi indépendante qu'elles le souhaitent.
Les projets graphiques GGI et Berlin sont de bons exemples de la raison pour laquelle il est bon d'avoir un certain degré d'indépendance. Ces deux projets ayant comme but de créer des composants graphiques améliorés fonctionnent très bien comme cela depuis plus d'un an.
Dans un projet Linux.org ``complètement intégré'', ils
deviendraient certainement :
Il existe des désaccords à propos du bien fondé de ces efforts particuliers ; le fait qu'ils aillent dans des voies indépendantes fait que jusqu'à présent, ils ne dérangent que ceux qui veulent bien être dérangés.
Par exemple, personnellement, j'aimerais voir GGI ``gagner'', au moins comme plate-forme permettant à X de s'exécuter très rapidement, et je pense que les efforts concernant Berlin ont été mal conduits. Mon jugement ne gène pourtant pas le projet Berlin. Dans le monde décentralisé de Linux, ils sont libres de réussir autant que d'échouer, indépendamment de ce que je veux ou de ce que je pense. Des développements peuvent être une perte de temps, mais ils n'affectent pas les autres projets Linux.
Si les projets étaient centralisés, l'échec d'un projet de développement critique ferait du mal à tout le monde. Par exemple, si j'étais l'autorité et que j'imposais que le système graphique GGI soit adopté, cela rendrait aléatoire la poursuite de certains projets relatifs à Linux et les nouvelles applications vulnérables à la possibilité que GGI puisse ne jamais être stable et vraiment utilisable.
Dans son modèle fortement réparti, Linux n'est a priori pas mis en danger par ce genre de problèmes.
En d'autres termes, Linux n'a pas de point central fixé, bien que Linus Torvalds exerce tout de même une grande influence.
Linux possède une large étendue d'utilisateurs ayant des désirs, besoins et moyens très divers.
Certains pourraient le décrire comme un OS (Operating System, ou système d'exploitation) serveur, comme tout autre UNIX. D'autres nient cela en clamant que Linux est le système le plus puissant existant pour les ordinateurs personnels et ne pensent pas qu'il est nécessaire de qu'un ordinateur puisse satisfaire plusieurs types d'utilisateurs.
Linux est un système très puissant qui peut vraiment être utilisé de beaucoup de manières différentes. Développer des applications se limitant à un mode particulier d'utilisation, alors qu'elles pourraient être facilement améliorées afin d'offrir davantage de flexibilité et de puissance, n'est franchement pas raisonnable. La plupart du temps, on peut avoir le beurre et l'argent du beurre avec Linux.
Trois sociétés ayant eu des niveaux de croissance spectaculaires sont issues de ce courant ``permettant l'indépendance''. Ce sont :
Cette société allemande de logiciels n'a pas essayé de fournir toute l'assistance technique liée à son logiciel, mais a encouragé l'utilisation de consultants externes. Il en a résulté que le système R/3 a été très soutenu par les plus grandes firmes internationales de consultants.
SAP AG et les sociétés de consultations travaillent actuellement en coopération parce qu'ils ont tous trouvé que cela leur était profitable.
L'indépendance des diverses composantes de cette société est, d'un point de vue organisationnel, technique, et économique, tout à fait remarquable. La domination actuelle de leur département d'imprimantes dans le marché mondial montre l'importance et la valeur de cette indépendance.
Il y a longtemps, les systèmes d'information des entreprises étaient largement dominés par IBM. Ils fournissaient des systèmes robustes, mais les développements du système étaient chers et exigeaient du temps, et les différents départements n'étaient guère satisfaits par les services proposés par le département des systèmes de gestion de l'information (MIS, ou Management Information Systems).
Les ordinateurs personnels sous MS-DOS et PC-DOS ont laissé aux différents départements l'occasion de posséder et contrôler leurs propres environnements logiciels, indépendants de la direction MIS centrale, et ceci à bas prix. Les PC (Personal Computers, ou ordinateurs individuels) ne présentent pas la robustesse des systèmes centraux mais il était très facile de faire effectuer aux PC des choses utiles à l'aide de logiciels standard comme les traitements de texte, les tableurs et les systèmes de gestion de bases de données. D'un point de vue politique, les licences logicielles pouvaient être acquises à bas prix au niveau du service plutôt que d'avoir à s'adresser au département MIS. Ceci a donné plus de pouvoir aux services concernés.
Le fait que ces ordinateurs individuels ne soient ni particulièrement fiables, ni particulièrement faciles à administrer, comparés aux ``mainframes'' (et ceci peut maintenant conduire à des problèmes cauchemardesques quand des services tentent de grossir leur réseau local de PC) ne contredit pas cela. Les PC ont été ``suffisamment bons'' pour ce qu'on leur demande, suffisamment utiles pour qu'on puisse y attacher de la valeur.