Comment Linux a-t-il été créé ? Les processus derrière la gestion de 13 500 développeurs

Vous avez probablement utilisé Linux aujourd’hui – surtout si vous n’avez pas d’iPhone. Et si vous avez navigué sur le web aujourd’hui, il y a de grandes chances que le site web que vous avez visité ait été servi par Linux, également.

Linux est un système d’exploitation, mais contrairement à des logiciels comme Microsoft Windows et macOS, Linux a été développé par une communauté auto-organisée de volontaires.

Au fil du temps, avec l’effort de plus de 10 000 développeurs et des processus évolutifs pour gérer l’ampleur du travail, le noyau Linux a atteint plus de 20 000 000 de lignes de code au total. Il constitue la base stable pour…

• Chaque téléphone et tablette Android sur la planète
• 66% des serveurs du monde
• 100% des 500 premiers superordinateurs

Cette technologie n’est pas venue d’une équipe orchestrée avec un épais livre de politique et des couches de gestion. Elle est venue de quelques politiques soigneusement choisies et culturellement intégrées, et d’une mission partagée.

Dans ce post, je regarde comment une technologie aussi essentielle, complexe et importante a pu être produite si efficacement sans structure de gestion traditionnelle. Mais d’abord…

Pourquoi le noyau Linux est-il si impressionnant ?

Un noyau est le cœur même d’un système d’exploitation. C’est l’orchestrateur de tous les autres processus logiciels sur votre ordinateur ou votre smartphone, répartissant les ressources et fournissant un moyen pour le matériel et le logiciel de communiquer.

Dans les mots de G. Pascal Zachary, le noyau d’un système d’exploitation peut être comparé à « un chef de personnel de maison qui était si diligent qu’il servait la famille à l’étage à tout moment, nuit ou jour sur appel, traitant chaque demande ». Le noyau assure le fonctionnement de la machine, quelles que soient les difficultés rencontrées. C’était un saut essentiel entre le monde où les ordinateurs ne pouvaient exécuter qu’une seule application à la fois, et le monde que nous connaissons aujourd’hui.

Le noyau Linux, basé sur UNIX, a été développé au début des années 1990 par Linus Torvalds.

En 1991, Torvalds avait publié la première version – seulement 10 000 lignes de code – et suscité l’enthousiasme de la communauté des développeurs de logiciels avec l’humble annonce par courriel que l’on voit ci-dessus.

Empowered by the collaborative power of internet for the first time in history, developers contributed their own coding skills and testing time for free as the kernel user base exploded in size. S’ils étaient prêts à expérimenter, les utilisateurs pouvaient essayer de bricoler un correctif s’ils trouvaient que quelque chose était cassé, et discuter de la façon d’améliorer le logiciel.

Comme Eric S. Raymond l’examine dans son livre sur les premiers logiciels open source, The Cathedral and The Bazaar, la gestion des développeurs du noyau par Linus Torvalds est devenue efficace, auto-organisée, et plus que capable de produire sans doute l’un des logiciels les plus complexes et les plus utilisés de la planète.

Dans cette pièce, j’examine les processus et les politiques qui sont apparus comme un soutien nécessaire au projet du noyau Linux au fur et à mesure de son évolution au fil des ans.

Comment, sans processus formel, alors qu’il était un étudiant en informatique de 21 ans, Torvalds a guidé le projet du noyau vers les sommets qu’il a atteints…

…Et qu’est-ce qui est si difficile dans la gestion des développeurs, de toute façon ?

Selon une recherche de Geneca, plus de 75% des dirigeants d’entreprises et de TI croient que leurs projets logiciels sont voués à l’échec. La difficulté de produire des logiciels fiables et de gérer ceux qui le font a donné naissance à d’innombrables livres de gestion, études de productivité et cadres de leadership.

« La complexité même des logiciels signifie qu’il est impossible de tester tous les chemins », écrit Paul Smyth, PDG de Kynetix, sur Finextra. « Une application logicielle est comme un iceberg – 90% de celle-ci n’est pas visible. La complexité majeure de l’application se trouve sous la ligne de flottaison ».

Tout projet logiciel de taille significative, qu’il s’agisse d’un CRM ou d’un système d’exploitation comme Microsoft Windows, est trop grand pour tenir dans la tête d’une seule personne. Il nécessite le partage des connaissances et la collaboration de nombreux contributeurs. Cela signifie que les développeurs travaillent sur des parties spécialisées de l’application tout en ayant besoin de comprendre comment leur travail affecte l’ensemble.

« Aucun esprit ne peut tout comprendre », remarquait le responsable d’une équipe de 250 développeurs de logiciels Microsoft alors qu’ils construisaient un système d’exploitation à partir de zéro, selon G. Zachary dans Show stoppers ! un livre qui raconte l’histoire d’une équipe de développeurs de logiciels Microsoft faisant la course pour terminer Windows NT en 1993.

Plus le projet est important, plus les changements peuvent être mis en œuvre lentement. Les recherches de Steve McConnell le prouvent, en constatant que le code est écrit à un rythme 5 à 10 fois plus lent sur les projets de plus de 10 000 000 de lignes. En outre, une étude des pratiques de développement de Microsoft a révélé qu’il y a environ 10-20 bogues pour chaque 1 000 lignes de code.

Malgré la taille du projet et le nombre de contributeurs, le développement du noyau Linux se produit rapidement et sa grande base d’utilisateurs enthousiastes attrape les bogues et écrit des correctifs pour expédier rapidement les améliorations.

Dans ses premiers jours de développement – vers 1991 – il n’était pas rare que Torvalds publie plus d’un nouveau noyau par jour. Maintenant, à un stade plus mature et dépendant de 80% des smartphones et de la majorité des serveurs internet, la période de sortie souhaitée est de 8 à 12 semaines. À chaque version, le noyau voit en moyenne 10 000 correctifs apportés par 2 000 développeurs – tous luttant avec plus de 20 000 000 de lignes de code.

Quelles sont les techniques et processus de gestion nécessaires pour orchestrer ce niveau de collaboration et de productivité ? Eh bien, ils n’ont pas été rédigés par un chef de service ou un auteur de livre d’affaires. Ils se sont développés de manière organique, avec les conseils du « dictateur bienveillant » du projet, Linus Torvalds.

Même dans sa forme naissante, le noyau Linux faisait l’objet de la collaboration de centaines de volontaires qui soumettaient leur travail directement à Torvalds pour révision. Comment un hacker de mauvaise humeur et antisocial a-t-il géré les différends, les contributions et la communication entre des milliers de développeurs pendant près de deux décennies ?

Comment la politique, le processus et 15 000 000 de lignes de code sont documentés

À la différence d’une organisation traditionnelle, les nouveaux développeurs du noyau ne sont pas strictement  » embarqués  » dans la communauté, mais on attend plutôt d’eux qu’ils aient pleinement lu et compris la documentation d’introduction. L’accent mis par le projet du noyau sur la documentation était une nécessité à la fois en raison de la complexité technique et du nombre de développeurs.

De nombreuses FAQ, how-tos et guides de démarrage existent dans le dépôt de documentation du noyau, et encore plus dans les wikis créés et maintenus par les développeurs du noyau à travers le monde.

La façon dont la documentation est écrite et améliorée reflète la façon dont le noyau est développé ; de manière collaborative, ouverte et incrémentale.

En tirant parti des yeux et des spécialisations d’un énorme groupe de personnes, la documentation peut être créée, testée et relue bien plus efficacement que si elle était faite par une équipe plus petite et dédiée. Pour plier la loi de Linus en termes qu’un rédacteur de contenu pourrait mieux comprendre : avec suffisamment de globes oculaires, toutes les coquilles sont évidentes.

En plus du matériel pour le support technique, la communauté de développement du noyau a créé une bibliothèque de documentation de processus conçue pour adoucir le côté humain de la collaboration.

Sur la page d’index de « A guide to the Kernel Development Process », un paragraphe dit:

« Le but de ce document est d’aider les développeurs (et leurs managers) à travailler avec la communauté de développement avec un minimum de frustration. C’est une tentative de documenter la façon dont cette communauté fonctionne d’une manière accessible à ceux qui ne sont pas intimement familiers avec le développement du noyau Linux (ou, en fait, le développement de logiciels libres en général). »

Personne ne naît avec une connaissance innée du système de contrôle de version git, ou de la façon de soumettre un patch à une liste de diffusion. C’est pourquoi le processus de développement doit être documenté – expliquer les mêmes informations de base à une personne à la fois n’est pas à l’échelle!

Comment la communication entre des milliers de développeurs est gérée

Les conversations entre développeurs se déroulaient à l’air libre, dans les listes de diffusion du développement du noyau. À ce jour, le courrier électronique reste l’outil privilégié en raison de sa simplicité. Ces listes de diffusion étaient archivées et organisées, constituant un corps de documentation et d’histoire vivante.

L’effet de la communication en public a un effet similaire aux avantages de l’utilisation d’un outil comme Slack aujourd’hui – toute information est rendue sûre et consultable, au lieu de s’évaporer. Afin de gérer un tel tuyau d’information, cependant, le projet du noyau a développé une politique de communication et l’a distribué comme partie de la documentation.

La communication et la collaboration à une telle échelle n’étaient pas possibles avant l’Internet, de sorte que les premiers projets comme celui-ci devaient écrire et distribuer des solutions rapides et efficaces pour la gestion de la communauté, l’étiquette et les problèmes de présentation du code.

La documentation du noyau comprend des règles pour soumettre des correctifs, de sorte qu’il est plus facile pour les autres de revoir, modifier et tester le code contribué. Cela signifie que les correctifs doivent être envoyés par courriel en texte brut, et non en pièce jointe. Les correctifs doivent être limités à une fois par courriel, et obéir à des directives de style de codage spécifiques :

Cette normalisation rigide est absolument nécessaire pour un projet aussi important que le noyau, comme pour les projets de toute taille. Elle permet de réduire les erreurs dans un espace où une seule erreur peut avoir un effet d’entraînement qui produit un code instable dans le futur, ou qui fait perdre du temps à de nombreux testeurs et développeurs.

Comment les décisions critiques sont (non) prises

Pour citer Torvalds:

« Le nom du jeu est d’éviter d’avoir à prendre une décision. En particulier, si quelqu’un vous dit « choisissez (a) ou (b), nous avons vraiment besoin que vous décidiez de cela », vous avez des problèmes en tant que manager. Les personnes que vous gérez ont intérêt à connaître les détails mieux que vous, donc s’ils s’adressent à vous pour une décision technique, vous êtes fichu. Vous n’êtes clairement pas compétent pour prendre cette décision à leur place. » – Documentation du développement du noyau Linux

En plus d’éviter une hiérarchie managériale, le projet Linux avait des règles et une documentation claires qui aidaient à prendre des décisions sans avoir besoin de discussions, de débats ou de (nombreuses) guerres de mots sur les listes de diffusion. Un coup d’œil aux archives vous montrera que la partie guerre de flammes n’est pas toujours possible, mais ce qui est possible est de créer une politique qui annule le fardeau de la décision.

« Ainsi, la clé pour éviter les grandes décisions devient de simplement éviter de faire des choses qui ne peuvent pas être défaites. Ne vous laissez pas entraîner dans un coin dont vous ne pouvez pas vous échapper. Un rat acculé peut être dangereux – un manager acculé est juste pitoyable. »

Show Stoppers ! révèle que la philosophie de Bill Gates est similaire. Il « admirait les programmeurs et les plaçait invariablement à la tête de projets, où ils pouvaient à la fois gérer et programmer, afin d’éviter une situation dans laquelle les managers professionnels, n’ayant soit aucune expérience de la programmation, soit des connaissances dépassées, avaient la mainmise ».

Comment les contributeurs sont orientés autour d’un objectif commun fort

Dans le cas de Linux, comme c’est le cas pour de nombreux projets open source populaires, le noyau n’a pas émergé en ayant été conçu de manière collaborative par un grand groupe de contributeurs ; il a plutôt été amélioré de manière incrémentale sans prendre de décisions qui déstabilisent la base solide du travail jusqu’à présent. Cela correspond bien à la philosophie de Torvalds sur la prise de décision dans la gestion, mais aussi à une philosophie intégrée dans le code lui-même.

Linux est basé sur UNIX, qui est un système d’exploitation antérieur conçu autour d’un ensemble de principes de type zen. Comme indiqué explicitement dans la philosophie d’UNIX :

« Concevez et construisez des logiciels, même des systèmes d’exploitation, pour les essayer rapidement, idéalement en quelques semaines. N’hésitez pas à jeter les parties maladroites et à les reconstruire. »

Tous les deux Torvalds et Raymond (qui ont cherché à reproduire le succès de la construction de la communauté de Torvalds) ont trouvé que libérer tôt et souvent a aidé à rallier les contributeurs autour d’un projet excitant, en croissance, dans lequel ils peuvent voir un avenir. Raymond l’a réduit à deux choses clés qu’un projet ne peut pas manquer de faire quand il est libéré dans le monde :

1. Run
2. Convaincre les co-développeurs potentiels (utilisateurs) que le projet peut évoluer vers quelque chose de grand bientôt

C’est avec ces mêmes principes que beaucoup de startups d’aujourd’hui se lancent – Process Street inclus :

Ci-haut, Process Street en 2014. Inscrivez-vous à un compte pour voir où nous en sommes.

Est-ce un processus reproductible ?

En surface, le soudain rassemblement de l’une des créations humaines les plus complexes ressemble à de l’alchimie. Mais, en décortiquant les composants, il est plus facile de voir un processus sous-jacent. Au moment où il écrivait The Cathedral and The Bazaar, Eric S. Raymond dirigeait simultanément le développement d’un client de messagerie électronique open source. En l’open-sourcing, Raymond tentait de reproduire l’implication de la communauté et le succès final du projet kernel.

Plusieurs des principes de base du modèle Bazaar, tel qu’il l’a inventé, seront immédiatement familiers à toute personne du monde des startups :

• Tout bon travail de logiciel commence par gratter la démangeaison personnelle d’un développeur.
• Traiter vos utilisateurs comme des co-développeurs est votre chemin le moins ennuyeux vers une amélioration rapide du code et un débogage efficace.
• Libérer tôt. Publiez souvent. Et écoutez vos clients.
• Si vous disposez d’une base de bêta-testeurs et de co-développeurs suffisamment importante, presque tous les problèmes seront caractérisés rapidement et la correction sera évidente pour quelqu’un.
• Si vous traitez vos bêta-testeurs comme s’ils étaient votre ressource la plus précieuse, ils répondront en devenant votre ressource la plus précieuse.
• La meilleure chose après avoir de bonnes idées est de reconnaître les bonnes idées de vos utilisateurs. Parfois, cette dernière est meilleure.
• Souvent, les solutions les plus frappantes et les plus innovantes viennent de la réalisation que votre concept du problème était erroné.
• Pour résoudre un problème intéressant, commencez par trouver un problème qui vous intéresse.
• Pourvu que le coordinateur du développement dispose d’un moyen de communication au moins aussi bon qu’Internet, et sache diriger sans coercition, plusieurs têtes valent inévitablement mieux qu’une.

En bref, c’est un processus reproductible. Et un qui a été adopté avec succès du monde de l’open source à la mentalité des startups. Il se manifeste dans agile, lean, six sigma, et les attitudes et la politique que les startups d’aujourd’hui ont développé. Bien qu’elle ne soit pas souvent mentionnée dans la même conversation, la méthodologie qui a évolué autour des premiers systèmes d’exploitation partage beaucoup avec l’idée actuelle d’itération sur un produit minimum viable.