Selon le créateur de SQLite, le secret de 26 ans de succès tient au fait de construire soi-même ses outils, de minimiser les contributions externes et de préserver la qualité du code par des tests rigoureux.
Cela révèle l’essence même de la « liberté », souvent négligée dans les écosystèmes open source complexes.
Sommaire
-
Le parcours de 26 ans de code de Richard Hipp, créateur de SQLite
- 1.1. La naissance de SQLite : une résolution de problème née sur un navire de guerre
- 1.2. La croissance de SQLite et son succès commercial
- 1.3. Licence, philosophie open source et développement d’outils maison
- 1.4. Des tests rigoureux et le développement logiciel à l’ère de l’IA
- 1.5. La durabilité de SQLite et sa dimension humaine
1. Le parcours de 26 ans de code de Richard Hipp, créateur de SQLite
Le créateur de SQLite, Richard Hipp, a mis en pratique, au fil de 26 années de développement, la philosophie suivante :
- développer lui-même les outils dont il a besoin ;
- réduire au minimum les contributions de code externes ;
- maintenir la qualité du code grâce à des tests rigoureux ;
- limiter les dépendances externes afin de préserver la liberté de développement.
1.1. La naissance de SQLite : une résolution de problème née sur un navire de guerre
SQLite a commencé sur un projet de navire de guerre
- SQLite est né dans le cadre d’un travail contractuel lié au navire de guerre USS Oscar Austin.
- À l’époque, Richard Hipp participait comme contractant de General Dynamics au projet de construction du DDG-79 chez Bath Iron Works.
- Le développement du système d’information de contrôle des avaries du navire rencontrait des difficultés.
- Une autre entreprise y avait investi des millions de dollars sans parvenir à livrer un résultat satisfaisant.
Les limites des systèmes de base de données existants
- Pour résoudre les problèmes du système de contrôle des avaries, Richard Hipp a développé un logiciel rapide fondé sur des heuristiques.
- Mais si le moteur de base de données Informix utilisé pour le stockage des données était arrêté, le logiciel cessait lui aussi de fonctionner.
- Le logiciel devait pourtant continuer à fonctionner même lorsque l’administrateur système arrêtait le moteur de base de données.
- Cela l’a amené à envisager une approche dans laquelle l’application lirait directement les données sur disque, sans processus de base de données séparé.
- Comme il était difficile, à l’époque, de trouver un moteur de base de données SQL répondant à ces exigences, il a dû le développer lui-même.
Une étude autodidacte des bases de données relationnelles
- À cette époque, la recherche sur Internet n’était pas aussi courante qu’aujourd’hui.
- Richard Hipp s’est rendu dans la bibliothèque d’une université locale pour consulter de la documentation et étudier la technologie des bases de données relationnelles.
- Des institutions comme le MIT, Harvard ou Berkeley menaient alors des recherches actives sur les bases de données relationnelles.
- Mais, en raison des contraintes géographiques, il n’était pas simple d’accéder facilement aux informations les plus récentes.
- Il a donc fini par étudier et implémenter lui-même la technologie de base de données dont il avait besoin.
1.2. La croissance de SQLite et son succès commercial
Un projet qui n’était pas destiné à générer des revenus
- SQLite n’a pas été développé dès le départ dans une logique de monétisation.
- Les premières versions ont été publiées comme logiciel gratuit.
- Au moment de son développement, il n’existait aucun projet d’en faire une activité ou d’en tirer des revenus.
Le premier contrat commercial avec Motorola
- Quelques années après la publication de SQLite, le fabricant de téléphones Motorola a pris contact.
- Motorola souhaitait intégrer SQLite dans ses téléphones mobiles.
- Cela a donné lieu au premier contrat commercial de SQLite.
- Le contrat reposait sur un prix fixe, et non sur une licence indexée sur l’usage.
La collaboration avec AOL
- Par la suite, America Online (AOL) a également signé un contrat pour inclure SQLite dans ses packages sur CD-ROM.
- Ce contrat aussi a été conclu sur la base d’un prix fixe.
- Richard Hipp a estimé rétrospectivement que le montant convenu était relativement faible au regard de la valeur de SQLite.
Le choix de SQLite par Symbian OS
- Symbian OS, utilisé dans des téléphones de Nokia et d’autres constructeurs, a mené des tests à l’aveugle pour sélectionner un moteur de base de données.
- Au total, 10 moteurs de base de données ont été évalués.
- À l’issue des tests, SQLite a été retenu.
- Au cours du processus, la question d’une dépendance excessive à un seul développeur clé a été soulevée.
- Il a alors été proposé de créer un consortium afin d’augmenter le bus factor.
Bus factor
Indicateur qui mesure si un projet peut continuer à être maintenu lorsque plusieurs personnes clés ne sont soudainement plus en mesure de travailler.
Un bus factor de 1 signifie qu’en l’absence d’un seul développeur clé, le maintien du projet peut devenir difficile.
La création du consortium et le développement à plein temps
- Mitchell Baker de Mozilla a apporté des conseils sur la création du consortium.
- C’est sur cette base que le consortium SQLite a été fondé.
- Après la création du consortium, Richard Hipp a pu se consacrer à SQLite à plein temps.
- En embauchant plusieurs collaborateurs, il a mis en place une organisation de développement modeste mais durable.
Un plan de support à long terme jusqu’en 2050
- En 2010, Airbus souhaitait utiliser SQLite dans l’avionique du projet A350.
- Airbus a demandé si SQLite pouvait être maintenu et supporté sur le long terme.
- En tenant compte du fait que la durée de vie d’une cellule d’avion est d’environ 40 ans, un engagement de support à long terme a été pris.
- Cet engagement relevait moins d’une obligation légale que d’un objectif de long terme poursuivi par le projet SQLite.
- Aujourd’hui, Richard Hipp fixe 2050 comme horizon personnel de fin de support pour SQLite.
- Cet objectif repose sur l’idée d’ajouter 50 ans au principe d’un « code au service des données », autrement dit de maintenir le code plus longtemps que la durée de vie attendue des données.
1.3. Licence, philosophie open source et développement d’outils maison
La naissance de la licence « prière »
- SQLite version 1 dépendait de la bibliothèque GDBM.
- Comme GDBM utilisait la licence GPL, SQLite ne pouvait qu’être influencé lui aussi par la GPL.
- Par la suite, afin de prendre en charge les range queries, un backend de stockage maison basé sur des B-trees a été développé.
- Une fois cette dépendance à une bibliothèque externe supprimée, il est devenu possible de choisir librement la licence.
Le choix du domaine public
- À l’époque, les licences les plus connues étaient essentiellement la licence MIT et la licence Berkeley.
- Plutôt que d’utiliser une licence comportant des clauses juridiques complexes, Richard Hipp a publié SQLite dans le domaine public (Public Domain).
- Il a découvert par la suite que la notion de domaine public n’était pas reconnue de manière identique dans tous les pays.
- Malgré cela, la politique de publication de SQLite est, dans les faits, perçue d’une manière proche d’une licence open source.
Le texte de la « prière »
Dans l’en-tête du code source de SQLite, au lieu d’une formulation juridique classique, figure un texte qui tient davantage de la bénédiction ou de la prière.
May you do good and not evil.
May you find forgiveness for yourself and forgive others.
May you share freely, never taking more than you give.
À mesure que SQLite est devenu l’une des bibliothèques logicielles les plus utilisées au monde, ce texte est lui aussi devenu le symbole de sa philosophie de licence singulière.
Une méthode de développement qui minimise les contributions externes
- SQLite n’accepte pas activement les pull requests comme un projet open source classique.
- Il maintient une approche dans laquelle les contributions externes sont réduites au minimum et où l’équipe centrale écrit et gère elle-même le code.
- Richard Hipp compare les pull requests à un « free puppy ».
- De la même façon qu’un chiot gratuit implique ensuite une responsabilité de soin et d’entretien, l’acceptation de code externe entraîne des responsabilités de long terme telles que :
- la maintenance du code ;
- les tests ;
- la documentation ;
- la correction des erreurs ;
- la gestion de la compatibilité avec d’autres plateformes ;
- la responsabilité technique sur la durée.
- Cette limitation des contributions externes fait partie des raisons pour lesquelles SQLite a pu conserver une qualité et une direction cohérentes pendant plus de 26 ans.
Exemples d’outils maison
Fossil
- Fossil est le système de gestion de versions maison créé pour gérer le projet SQLite.
- Il a été développé à une époque proche de celle de Git.
- Au-delà de la gestion du code source, il fournit de manière intégrée les fonctions suivantes :
- gestion de versions ;
- suivi des issues ;
- wiki ;
- forum ;
- interface web.
- Fossil lui-même est construit sur SQLite.
- À ce titre, Fossil joue aussi le rôle de plateforme de bêta test concrète pour SQLite.
- Le développement et l’exploitation de Fossil ont permis d’identifier les points faibles de SQLite du point de vue d’un développeur d’applications, puis de les améliorer.
- Richard Hipp estime que si Git convient aux grands projets distribués comme le noyau Linux, Fossil est mieux adapté aux petits projets comme SQLite.
Lemon
- Lemon est l’outil développé pour générer le parseur SQL de SQLite.
- Il a été créé en interne au lieu d’utiliser Yacc ou Bison.
- Parce qu’il s’agit d’un outil maison, la méthode de génération du parseur a pu être améliorée librement en fonction des besoins de SQLite.
Les outils maison et la philosophie de la liberté
- Pour Richard Hipp, développer ses propres outils n’est pas une simple préférence technique.
- Il considère que fabriquer soi-même les outils dont on a besoin est une manière de prendre soin de soi.
- Réduire les dépendances externes permet d’être moins affecté par les décisions d’autres projets ou entreprises.
- Selon lui, cette indépendance élargit directement la liberté du développeur.
- Il dit néanmoins ressentir aussi une forme de pression et d’inquiétude face au fait que SQLite soit devenu une dépendance essentielle de très nombreux systèmes dans le monde.
1.4. Des tests rigoureux et le développement logiciel à l’ère de l’IA
Les tests, clé du succès de SQLite
- L’un des facteurs essentiels de la stabilité durable de SQLite est l’extrême rigueur de ses tests.
- L’équipe de développement ne se contente pas de vérifier qu’une fonctionnalité marche : elle valide aussi de nombreux cas limites et plateformes variées.
- Les tests sont considérés comme si importants que leur volume dépasse largement celui du code produit lui-même.
L’application du standard DO-178B
- L’équipe SQLite a appliqué à ses tests l’approche du standard DO-178B, utilisé pour le développement logiciel aéronautique.
- Cela a permis d’augmenter systématiquement la couverture de test.
- Une fois un niveau de couverture de type DO-178B atteint au début du développement d’Android, les rapports de bugs ont presque disparu.
- Cette expérience a confirmé que des tests rigoureux ont un effet direct sur l’amélioration réelle de la stabilité logicielle.
La découverte de nouveaux bugs grâce au fuzzing
- Par la suite, des techniques de profile-guided fuzzing sont apparues.
- Le fuzzing consiste à injecter dans un programme des données aléatoires ou transformées afin de détecter des erreurs inattendues.
- De nouveaux types de bugs, difficiles à découvrir même avec des tests de niveau DO-178C, ont été trouvés grâce au fuzzing.
- Cela montre qu’une forte couverture de test ne suffit pas, à elle seule, à détecter toutes les erreurs.
Les bugs découverts par l’IA
- Récemment, on a aussi vu apparaître des cas où l’IA est utilisée pour rechercher des bugs ou rédiger des rapports de bugs.
- Le projet SQLite a lui aussi reçu des rapports de bugs soupçonnés d’avoir été générés par IA.
- L’IA pourrait devenir un nouvel outil de vérification logicielle venant compléter les tests existants et le fuzzing.
L’évaluation de l’IA par Richard Hipp
- Richard Hipp dit que son opinion sur l’IA peut changer d’un jour à l’autre.
- Pour l’instant, il l’utilise comme un outil très utile.
- Il a raconté qu’en posant à ChatGPT une question sur du code SQLite, l’IA lui avait répondu de la manière suivante :
« Bien sûr, vous le savez déjà… »
- Il explique avoir ressenti quelque chose d’assez troublant en voyant l’IA parler de son propre code comme si elle le connaissait mieux que lui.
- L’IA est utile pour explorer de l’information et faire émerger des idées.
- Mais elle n’est pas toujours exacte et peut fournir des informations erronées dans une formulation très convaincante.
- Du code généré par IA a parfois posé des problèmes de compatibilité, fonctionnant sur certains systèmes d’exploitation mais pas sur d’autres.
- Les résultats produits par l’IA doivent donc eux aussi être relus et corrigés par des humains.
Un conseil adressé aux jeunes développeurs
- Richard Hipp accueille favorablement les tentatives de forker SQLite pour créer une meilleure base de données.
- Il souligne néanmoins que, pour atteindre un niveau comparable à SQLite, il faut :
- plus de 25 ans de développement continu ;
- un dévouement obstiné à un seul sujet ;
- de longues années de tests et d’améliorations ;
- une observation continue des besoins des utilisateurs ;
- une expérience accumulée au fil d’échecs répétés.
- Un grand logiciel ne se construit pas en peu de temps.
- Il estime que l’IA pourrait profondément transformer la manière de développer des logiciels, mais qu’il reste difficile de prévoir à quoi ressemblera réellement l’avenir.
1.5. La durabilité de SQLite et sa dimension humaine
Pourquoi cela a pu durer 26 ans
- Richard Hipp explique le succès de SQLite moins par ses propres capacités que par la providence divine et la chance.
- Il dit ne pas se considérer comme un programmeur particulièrement exceptionnel.
- Il estime cependant que certains traits ont aidé au développement de SQLite :
- une tendance à maintenir obstinément sa propre manière de faire ;
- une propension à remettre en cause les idées reçues ;
- l’habitude de fabriquer lui-même les outils nécessaires ;
- une capacité à se concentrer longtemps sur un même problème ;
- le plaisir pris dans le processus de développement lui-même.
- Il explique que le fait de réfléchir sans cesse à la manière de mieux construire SQLite a été, en soi, fondamental.
Les avantages d’une petite équipe
- Richard Hipp dit ne pas être particulièrement doué pour fréquenter beaucoup de gens ou gérer les relations politiques au sein d’une organisation.
- C’est en partie pour cette raison qu’il a maintenu une petite équipe autour de SQLite.
- Il estime finalement que cette structure réduite a favorisé la cohérence de la direction de SQLite et la rapidité des décisions.
- Il reconnaît ne pas avoir la capacité, comme Linus Torvalds pour Linux, de coordonner les relations avec un très grand nombre de développeurs.
La gestion de l’entreprise avec son épouse Ginger
- Richard Hipp dirige l’entreprise avec son épouse, Ginger.
- Tous deux maintiennent un travail d’équipe souple, allant jusqu’à échanger leurs rôles selon les situations.
- Ginger est musicienne et sait aussi très bien aider d’autres musiciens confrontés à des problèmes informatiques.
- Richard Hipp raconte que Ginger est plus connue que lui dans la communauté locale.
La dimension humaine du développement logiciel
- Richard Hipp ne voit pas le logiciel comme un simple assemblage de code ou de technologie.
- Il insiste sur l’importance, dans le développement logiciel, des éléments humains : émotions des développeurs, relations de collaboration, obsessions, échecs, sentiment d’accomplissement.
- Le logiciel est un produit complexe et abstrait, mais derrière lui se trouvent toujours les histoires des personnes qui l’ont créé.
Livre recommandé : The Soul of a New Machine
- Richard Hipp recommande 《The Soul of a New Machine》 comme ouvrage permettant de comprendre la dimension humaine du logiciel et du développement informatique.
- Ce livre ne se contente pas d’expliquer la technique informatique.
- Il traite aussi d’éléments comme :
- la passion des développeurs ;
- les conflits internes aux organisations ;
- les défis techniques ;
- l’échec et la frustration ;
- la collaboration et la concurrence ;
- les émotions liées au processus de création.
- Il souligne l’importance de pouvoir comprendre en profondeur une technologie complexe tout en la racontant sous un angle humain.
Conclusion
Si SQLite a pu être maintenu avec succès pendant plus de 26 ans, ce n’est pas uniquement grâce à une excellence technique hors norme.
Les principaux facteurs de ce succès peuvent être résumés ainsi :
- Les technologies nécessaires ont été développées directement pour résoudre de vrais problèmes.
- Les dépendances externes ont été réduites afin de conserver le contrôle du projet.
- La responsabilité de maintenance à long terme a été jugée plus importante que les contributions externes.
- Les outils nécessaires, comme Fossil et Lemon, ont été développés en interne.
- Des tests d’un niveau comparable à celui du logiciel aéronautique ont été appliqués.
- L’IA et les nouvelles techniques de développement ont été utilisées sans pour autant accorder une confiance aveugle à leurs résultats.
- Le projet a été mené sur la base d’une petite équipe et de relations humaines fortes.
- Une immersion obstinée et de long terme dans un même sujet a été maintenue.
Le point essentiel que montre le cas de SQLite est que la liberté n’est pas l’absence totale de contraintes, mais la capacité à assumer soi-même la responsabilité et le contrôle des outils et du code que l’on utilise.
La manière dont SQLite réduit ses dépendances externes, construit ses propres outils et vérifie tout de façon rigoureuse constitue un exemple important de ce que peut être un développement logiciel durable, même à l’ère de l’IA.
4 commentaires
Le DO-178 de la RTCA est un guide suffisamment court pour qu’il soit réellement possible de le lire et de l’appliquer. Il est largement utilisé dans l’industrie aéronautique.
https://studylib.net/doc/27132454/rtca-do-178b
« Plus de 25 ans de développement continu », c’est vraiment impressionnant...
C’est génial… on dirait presque un film.
Quel état d’esprit incroyable.