- Lancée en 1986, PostgreSQL voit la population qui assure réellement la maintenance de son code cœur vieillir, ce qui fait émerger une question de pérennité : qui poursuivra ce travail dans 20 ans ?
- En 2022, 192 développeurs ont été auteurs principaux d’au moins un commit, mais 66 % du nouveau code a été écrit par 14 personnes et 90 % par 40 personnes, signe d’une forte concentration
- L’âge moyen de la communauté de développement centrale est d’environ 50 ans, et Tom Lane, à 68 ans, continue de jouer un rôle central dans le projet
- Neon investit délibérément dans la formation de la prochaine génération, en recrutant des profils juniors pour les faire évoluer de contributor à committer, puis maintainer, plutôt qu’en embauchant uniquement des talents déjà confirmés
- Pour assurer la maintenance durable du projet, il faut de l’intentionnalité, des financements et un intérêt personnel éclairé (enlightened self interest)
Le vieillissement de PostgreSQL et le problème des équipes de maintenance
- Lancé en 1986, PostgreSQL est devenu un choix par défaut pour une grande partie du développement logiciel moderne, mais avec le temps se pose la question de la continuité des personnes qui construisent réellement la base de données
- La question est de savoir combien de temps encore ces personnes pourront continuer à assumer le gros du travail (heavy lifting) de maintenance d’une base de code critique dont dépendent tant d’utilisateurs
- Postgres reste un projet porté par un petit groupe très soudé
Statistiques des contributeurs en 2022
- Robert Haas, chief database scientist chez EnterpriseDB et committer Postgres, a publié ces chiffres dans son billet régulier « Who Contributed to PostgreSQL Development in 2022? »
- En 2022, 192 personnes étaient auteurs principaux (principal author) d’au moins un commit PostgreSQL
- 66 % des nouvelles lignes de code ont été écrites par l’une de 14 personnes
- 90 % des nouvelles lignes de code ont été écrites par l’une de 40 personnes
Structure d’âge de la communauté centrale
- La communauté centrale de développement est relativement âgée, avec une moyenne d’environ 50 ans
- Tom Lane, de Crunchy Data, a 68 ans et continue de jouer le rôle de pivot (fulcrum) du projet Postgres
Gouvernance ouverte et la question de dans 20 ans
- La gouvernance ouverte de Postgres constitue une base fiable, particulièrement rafraîchissante à une époque où les changements unilatéraux de licence dans l’open source commercial sont fréquents
- Du point de vue de la pérennité de l’open source, si l’on suppose que Postgres sera toujours en bonne santé dans 20 ans, cela soulève la question : qui fera ce travail en 2043 ?
Neon et la discussion avec Nikita Shamgunov
- Une conversation avec le CEO de Neon, Nikita Shamgunov, a porté sur le vieillissement des projets techniques et son lien avec leur pérennité
-
Présentation de Neon
- Neon est une base de données Postgres entièrement managée, optimisée pour les applications serverless, qui sépare le stockage et le calcul selon le principe de conception « la base de données n’est qu’une URL »
- Le service prend en charge le branching, permettant des déploiements en preview, ce qui a conduit à un partenariat avec Vercel
- Son ambition est de rendre cela « simple, moderne, avec une API zero config »
- L’entreprise compte 62 employés, a levé 108 millions de dollars ($108m) et concurrence notamment Supabase
-
Différence entre committer et contributor
- Shamgunov : « Les committers Postgres ont surtout la cinquantaine, la soixantaine ou la quarantaine, et il y a peu de trentenaires »
- Devenir committer demande beaucoup d’efforts, mais devenir contributor consiste simplement à écrire du bon code
Investir dans la prochaine génération de committers
- Neon investit délibérément dans la prochaine génération de contributors, committers et maintainers
- Pour beaucoup d’entreprises, le choix naturel consiste à recruter des talents déjà au sommet plutôt qu’à en former de nouveaux
- Shamgunov : « Nous avons discuté de la possibilité d’embaucher davantage de committers Postgres, mais il n’était pas certain que ce soit le meilleur usage de notre argent »
- « Mieux vaut former de nouvelles personnes, et c’est ainsi que nous pouvons continuer à faire grandir l’équipe Postgres »
- Shamgunov souligne que recruter et former des profils juniors pour en faire des committers, puis des maintainers, est essentiel à l’évolution continue du moteur Postgres
Licence et intérêt personnel éclairé
- L’IP de Neon est actuellement sous licence permissive, mais Shamgunov n’est pas un puriste de l’open source
- À l’avenir, Neon pourrait choisir, comme Redis, MongoDB ou Elastic, de relicencier (relicense) ses technologies sous des conditions plus restrictives
- En revanche, le code déjà contribué à Postgres ne serait pas affecté par une telle décision
- Le fait d’avoir des maintainers clés de Postgres en interne relève d’un intérêt personnel éclairé (enlightened self interest) : cela pousse l’entreprise à rester honnête et, quelle que soit la décision prise, la communauté et la base de code centrale en bénéficient
Le vieillissement des cohortes, un phénomène général
- Le vieillissement des cohortes n’est pas un problème propre à Postgres ; comme dans le cas du Y2K par le passé, les communautés et les écosystèmes vieillissent, ce qui peut créer des difficultés sur les plans technique, humain et générationnel
- IBM a par exemple réussi à attirer de jeunes développeurs vers le monde du mainframe grâce à des programmes universitaires et de formation professionnelle
- Il existe aussi de nombreux projets, utilisés par des millions de personnes, maintenus par une ou deux personnes seulement, sans le soutien d’entreprises comme Postgres ou Kubernetes
Conclusion — l’intentionnalité de la maintenance
- Postgres n’a absolument aucun mal à attirer de nouveaux utilisateurs et reste une plateforme extrêmement populaire, y compris comme choix par défaut pour les développeurs de 22 ans aujourd’hui
- Mais pour garantir la maintenance durable du projet, il faut de l’intentionnalité, des financements et un intérêt personnel éclairé
Divulgation
- Neon n’est pas client de RedMonk ; Crunchy Data, IBM et Vercel le sont, et ce billet a été publié de manière indépendante, sans lien avec ces relations clients
1 commentaires
Avis sur Hacker News
J’ai 46 ans, mais j’aimerais faire partie de la prochaine génération, et il y aura sûrement aussi des personnes plus jeunes
Ma dernière présentation à PGCon portait sur les zones d’ombre à connaître pour hacker Postgres, en particulier la phase d’exécution et les tentatives de remplir
TupleTableSlotJe ne suis pas forcément la personne la mieux placée, mais il arrive qu’une personne qui apprend sache mieux ce dont les apprenants ont besoin
Il y a quelque temps, j’ai aussi rédigé la table des matières d’un livre sur la façon de contribuer à Postgres, et je pense qu’il s’en vendrait au moins 10 exemplaires
Une publication en ligne en feuilleton serait peut-être préférable ; dans un cas comme dans l’autre, je me demande s’il y aurait des personnes intéressées
Pour l’instant, Postgres relève plutôt du hobby pour moi, mais si quelqu’un cherche une personne pour faire de la contribution open source à Postgres à plein temps, je serais prêt à en discuter
Une bonne partie de la prochaine génération actuelle est aussi arrivée assez tard à Postgres
Tom aussi se dévaloriserait, mais il a travaillé plusieurs années dans l’image et a participé, d’une manière ou d’une autre, à la création de tiff, jpg et png, avant de découvrir Postgres et de commencer à y travailler
Il produit beaucoup de contenu sur la façon de commencer à contribuer à Postgres, et il est aussi ouvert aux échanges avec d’autres utilisateurs passionnés de PG
Une collaboration ou des conseils pourraient être possibles : https://www.youtube.com/watch?v=rihfAnd_leM
On peut le contacter par e-mail à x4mmm@.ru ou sur Twitter @x4mmmmmm
Maintenant que la barrière d’entrée a baissé, j’espère que davantage de personnes prendront une retraite anticipée pour contribuer à l’open source
Certains éditeurs permettent aux lecteurs en accès anticipé de signaler des erreurs : https://nostarch.com/early-access-program
C’est suffisamment intéressant pour que mon objectif soit de pouvoir prendre une retraite anticipée et hacker Postgres à plein temps
Il y a du réseau, du stockage, des données, des algorithmes, etc.
Honnêtement, C est le moindre des problèmes, et Postgres a un bon style de code, assez cohérent
La difficulté, c’est la complexité de l’architecture interne, et si la communauté est petite, cela peut aussi jouer sur la vitesse à laquelle on obtient de l’aide
Je me demande si, à l’avenir, les bases de code en C auront du mal à trouver des mainteneurs
Postgres bénéficie d’un support commercial et d’une forte inertie, mais il semble manquer de filières amenant des développeurs C expérimentés
C reste un langage vivant, les utilisateurs actifs ne manquent pas, et pour quelqu’un qui fait de la programmation système dans un autre langage, la courbe d’apprentissage n’est pas si raide
Pour les développeurs web et applicatifs d’aujourd’hui, il existe un voile opaque entre l’architecture des systèmes bas niveau et eux, ce qui peut rendre C intimidant ; mais les programmeurs système en C++ ou Rust travaillent déjà derrière ce voile, avec des gants encore plus épais
Ils ont souvent été exposés à C, ne serait-ce que dans le cadre de leur formation ou d’expérimentations, et s’ils doivent s’en occuper professionnellement, ils peuvent l’étudier délibérément et s’adapter à ses pièges dangereux
Il existe des arguments contre le choix de C pour de nouveaux projets système, mais hormis le manque de programmeurs système en général, je ne vois pas de grosse inquiétude immédiate pour trouver des mainteneurs de code existant
Je n’ai pas fait de mesure scientifique, mais le niveau moyen en C des nouveaux contributeurs semble plus faible qu’avant ; bien sûr, c’est peut-être ma barbe grise qui parle
Jusqu’ici, les gens « apprennent sur le tas », mais je ne sais pas exactement à quel point l’écart est grand
Un jour, il faudra sans doute faciliter l’usage d’autres langages dans certaines parties du système, par exemple pour l’implémentation de types de données dans le cœur, mais en pratique cela semble encore assez lointain
La vraie difficulté est d’acquérir les bonnes connaissances du domaine, et il faut beaucoup de temps pour se familiariser avec l’ensemble du système
Je connais très peu de développeurs Rust ou C++ expérimentés qui ne soient pas aussi à l’aise en C
En revanche, je me demande quand davantage de bases de code en C commenceront à extraire des modules pour les remplacer par Rust
Cela se produit déjà dans Linux, curl, des projets C++ comme Chrome, plusieurs produits MS, Amazon S3, etc.
Le refus le plus explicite que je connaisse est OpenBSD, parce qu’ils veulent garder le bootstrap et la chaîne d’outils d’installation par défaut de petite taille
Même le système de types de TypeScript est nettement plus complexe que C
Ou alors je viens peut-être de révéler mon ignorance de la complexité de C
J’ai beaucoup réfléchi à ce sujet
La communauté a longtemps connu des hauts et des bas, et je vais dire quelques choses dans l’idée de partager un peu plus sur la communauté PG
Pendant plusieurs années, il n’y a eu aucun nouveau committer, et récemment l’équipe a cherché plus délibérément à ajouter de nouveaux committers et à retirer les personnes qui ne participent plus
Il y a environ 15 ans, il y a eu une période où pas mal de jeunes obtenaient les droits de commit, et je me souviens de trois personnes qui les ont eus avant 25 ans, peut-être même toutes avant 22 ans
L’une d’elles est sortie de la communauté Postgres peu après, une autre a été discrètement occupée par autre chose pendant plus de dix ans avant de revenir, et la dernière est restée activement impliquée
Je pense que le malaise suscité par les personnes qui disparaissent après avoir reçu les droits de commit a ralenti l’ajout de nouvelles personnes pendant quelques années
En résumé, cela veut dire qu’il est difficile d’obtenir les droits de commit sur Postgres juste après l’université
Une donnée intéressante mais difficile à collecter serait l’âge auquel les gens deviennent committers Postgres
Je ne serais pas surpris que l’âge moyen d’obtention des droits de commit soit proche de 45 ans
Beaucoup de contributeurs arrivent sur Postgres après avoir travaillé sur d’autres systèmes, ou bien ne commencent à envisager de contribuer qu’après avoir acquis une certaine expérience, parce que la manière de contribuer en envoyant des patches sur des listes de diffusion paraît intimidante
L’histoire de son premier commit est excellente
En testant le comportement SQL chez Materialize, il a voulu vérifier si les deux systèmes traitaient les fonctions d’intervalle de la même façon, et il a minutieusement essayé des choses comme
select interval '0.5 months 2147483647 days';On peut l’essayer directement sur dbfiddle : https://www.db-fiddle.com/f/ijT76fsmL99bHvXxhAtf7j/0
Au lieu d’une erreur, Postgres renvoyait une valeur incorrecte,
{"days":-2147483634}, et on peut en lire la raison ici : https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit...Il l’a donc naturellement corrigé dans Postgres, ce qui fait que c’est correctement géré à partir de la version 15 : https://www.db-fiddle.com/f/i3KikCb72AN1EZpywErZvr/1
J’aime tellement Postgres que j’ai même un tatouage PG, mais les deux voies de contribution ne sont pas simples
Même si l’on essaie de contribuer sur son temps libre en tant qu’utilisateur lambda, il n’y a pas beaucoup de tickets de type « bon premier ticket », et il est difficile de se lancer sans connaître au moins un peu le contexte et les raisons historiques de plusieurs parties de l’architecture de PG
Faire relire un patch par des gens comme Tom ou Andres peut aussi être intimidant
La voie qui consiste à rejoindre comme développeur une entreprise PG payante comme EDB, PG Pros ou Crunchy ressemble aussi à un problème de la poule et de l’œuf
Il est difficile d’être recruté comme junior sans expérience préalable du hacking PG, mais le chemin pour acquérir cette expérience n’est pas simple non plus
Si ce n’était pas mon entreprise actuelle, j’aimerais travailler dans un endroit où l’on fait du PG, mais il n’y a pas beaucoup de points d’entrée réalistes
Pour les 10 derniers committers, j’ai utilisé quelques commandes git comme celles ci-dessous afin de comparer le moment où leur nom apparaît pour la première fois dans un message de commit et le moment de leur premier commit en tant que committer
La durée moyenne de participation était d’environ 8,9 ans en ne comparant que le mois et l’année, et le cas le plus court était encore d’environ 6,5 ans
Une meilleure analyse serait possible, mais l’objectif était d’avoir un ordre de grandeur
git log --grep 'Name' --format=%cs | sort | head -1git log --author 'Name' --format=%cs | sort | head -1À l’époque, il était peut-être plus accessible à une personne de 22 ans, et il était peut-être possible d’en comprendre davantage de parties
De plus, à l’époque, C était un langage standard, alors qu’aujourd’hui les jeunes développeurs sont plus susceptibles de programmer en Rust qu’en C
Je ne savais absolument pas qu’il y avait eu une concentration de personnes ayant reçu les droits de commit avant 22 ans
Je suis un nouveau contributeur qui a commencé à contribuer à Postgres il y a 5 mois, et j’aurai 27 ans à la fin du mois.
Je n’ai pas encore apporté beaucoup de contributions significatives, mais j’ai quelques commits et, à l’avenir, j’aimerais notamment faciliter la compilation des extensions Postgres avec Meson et, si possible, faire disparaître rapidement le build autotools.
Vous me verrez peut-être bientôt aussi dans les dépôts pgbouncer ou pgvector.
Ce qui m’a amené à contribuer, c’est que j’étais épuisé par l’entreprise de conseil logiciel où j’avais travaillé pendant 3 ans.
À l’origine, je voulais vivre comme quelqu’un du logiciel système open source, et j’ai trouvé chez Micron un poste sur un moteur de stockage open source.
Honnêtement, j’ai eu de la chance, mais l’offre semblait écrite pour moi, alors j’ai postulé, et j’ai travaillé avec plaisir sur ce projet pendant 2,5 ans.
Malheureusement, fin février, Micron a licencié toute l’équipe, puis MongoDB m’a proposé un poste sur les drivers C/C++ avant de retirer son offre.
Après cela, j’ai commencé à m’appuyer davantage sur mon réseau, et j’ai demandé à une connaissance de #mesonbuild sur Libera.Chat/Matrix, qui travaillait sur Postgres, s’il existait des postes liés à Postgres correspondant à mon profil.
Il m’a dit que Neon recrutait ; j’ai postulé dans l’équipe moteur de stockage, mais lors du premier entretien, la personne qui allait devenir plus tard mon manager a estimé que je correspondrais mieux à la nouvelle équipe Postgres qu’il était en train de monter, c’est-à-dire une équipe qui contribue à Postgres upstream.
Je suis très reconnaissant envers Neon de m’avoir donné cette chance.
Le sujet de cet article est intéressant, car il venait justement d’émerger pendant que je discutais avec d’autres jeunes contributeurs Postgres à PGConf NYC.
Même les petits patches sont difficiles à faire examiner, et plus votre nom semble connu dans la communauté, plus vous obtenez de reviews, ce qui crée un problème circulaire.
La structure des listes de diffusion Postgres n’est pas idéale non plus : il faut boire directement au tuyau d’incendie qu’est pgsql-hackers, alors que LKML est découpée en plusieurs sous-systèmes.
Les forges de code modernes ont l’avantage de permettre de s’abonner à des tags précis de PR/issues, mais pgsql-hackers n’offre actuellement rien de ce genre.
Ajouter une entrée au commitfest est aussi assez pénible, et pour faire passer la CI complète de Postgres, il faut l’y mettre ; ensuite, il faut encore vérifier soi-même ou espérer qu’un committer vous signale un échec de CI.
Les rapports de bugs arrivent eux aussi sur la liste de diffusion pgsql-bugs, et Postgres n’a pas d’équivalent au bugzilla de Linux.
Les patches sont envoyés en pièces jointes d’e-mail, pas forcément au format git-format-patch, tandis que LKML semble, à vue d’œil, utiliser exclusivement git-send-email.
Dans l’ensemble, les outils de la communauté des contributeurs Postgres semblent surtout adaptés aux personnes qui y sont profondément immergées depuis plus de 15 ans.
Je ne veux pas transformer cela en billet disant « utilisons GitHub/GitLab » ; au contraire, je pense que l’e-mail est supérieur pour discuter des patches, mais les outils autour des listes de diffusion pourraient être améliorés.
Tout est trop séparé, et je trouve que SourceHut s’en sort bien pour rendre le développement basé sur les listes de diffusion plus accessible aux contributeurs du quotidien.
Issues, listes de diffusion, CI/CD et dépôts y sont tous reliés, au lieu d’être répartis entre des services séparés comme c’est actuellement le cas pour Postgres.
Ce commentaire pourrait lui-même devenir un billet de blog à part entière un jour, mais je vais m’arrêter là.
Si vous débutez dans les contributions à Postgres, je pense que je pourrais partager mon expérience ; vous pouvez m’écrire à tristan neon.tech ou tristan partin.io.
Un autre contributeur Postgres estimait aussi qu’il pourrait être utile que les contributeurs non committers se réunissent chaque mois pour parler des patches sur lesquels ils travaillent ou qu’ils ont publiés, et recevoir des reviews de pairs.
Tristan pourrait prendre l’initiative d’une rencontre en ligne.
Melanie Plageman était elle aussi intéressée par ce genre d’idée, et nous avions brièvement discuté de différentes formes d’office hours.
Cela pourrait devenir un bon article, et cela ressemble à quelque chose que la communauté Postgres pourrait améliorer assez facilement du point de vue de l’organisation et des processus.
En revanche, je suis moins convaincu par la partie sur la « notoriété du nom », et il semble aussi y avoir beaucoup de pertes à l’autre extrémité.
Le problème de pgsql-hackers qui donne l’impression d’être un tuyau d’incendie est réel, et je pense qu’il s’est nettement aggravé ces dernières années.
On peut activer la CI sur le dépôt sans passer par commitfest : https://github.com/postgres/postgres/blob/master/src/tools/c...
C’est la même CI que celle qui tourne pour les entrées du commitfest.
Je déteste vraiment que les rapports de bugs passent par une liste de diffusion, et j’en rate moi aussi constamment.
Je trouve aussi que le bugzilla du kernel est assez inutile, mais il ne serait pas difficile de faire mieux que ça.
Je ne trouve pas non plus que la gestion des patches à la LKML soit bonne, notamment parce que chaque révision d’un patchset crée un nouveau thread, ce qui ne rend pas le suivi très facile.
Même après environ 15 ans de participation au développement, je ne dirais pas que les outils actuels fonctionnent particulièrement bien.
Le processus de développement a certes quelque peu évolué au fil du temps, mais pas au niveau nécessaire.
Faire évoluer une communauté avec autant de barbes grises que celle de PG demande beaucoup d’efforts ; ce n’est pas impossible, mais ce n’est pas facile.
Personnellement, je déteste fortement utiliser GitHub ou GitLab pour des travaux complexes, mais je pense qu’il faudrait accepter les PR/MR via l’un ou l’autre afin de faciliter la vie des nouveaux contributeurs.
Cela dit, ce n’est pas une décision qui m’appartient seul.
Je pense qu’il n’y aurait pas plus de deux ou trois personnes opposées à l’idée que l’e-mail est supérieur pour discuter des patches, mais que les outils autour doivent être améliorés.
Le problème, c’est que beaucoup de gens préfèrent passer leur temps à hacker Postgres plutôt qu’à travailler sur les outils ou l’intégration du processus de développement.
J’ai fait un peu de travail sur Postgres avec l’aide de pgrx, et je peux le recommander comme plateforme pour construire des solutions de données.
La chaîne de CMU était aussi une bonne ressource : https://www.youtube.com/@CMUDatabaseGroup
Par exemple, même si l’on veut écrire un nouveau handler de Table Access Method, le SDK pg-sys de base contient bien des bindings liés à TableAM, mais il n’existe pas de documentation ni d’exemple expliquant comment les utiliser depuis Rust.
On en vient à observer que la plupart des gens qui arrivent dans l’IT aujourd’hui ne pensent qu’à l’argent, et qu’il n’y a plus vraiment beaucoup de passionnés
C’est très triste, et j’ai l’impression que beaucoup de projets open source meurent à cause de cela
C’est une logique du type « copier-coller depuis Stack Overflow et toucher son salaire », sans contribution ni aide en retour
Je ne dis pas que tout le monde est comme ça, mais d’après ce que j’ai pu observer de près et les conversations que j’ai eues en travaillant dans plusieurs entreprises, le ratio était d’environ 19:1
À titre de référence, je travaille chaque jour pour deux entreprises, car je termine le travail beaucoup trop vite par rapport aux standards et je perds souvent du temps à attendre des réunions
J’ai aussi beaucoup fait de petits boulots à côté pour travailler sur des choses intéressantes, et souvent gratuitement pour essayer du nouveau matériel ou expérimenter
Les clauses de cession des inventions et les clauses sur les activités extérieures dans les contrats augmentent les barrières à la contribution
Je suis d’accord pour dire que Postgres n’a pas de mal à attirer de nouveaux utilisateurs
Moi aussi, j’utilise Postgres pour plusieurs applications auto-hébergées
En revanche, pour les applications PHP, je continue d’utiliser MariaDB quand c’est la base de données par défaut ou la seule disponible
En résumé, il semble que la base des contributeurs de PostgreSQL vieillisse, et que Neon élargisse la base de développeurs en recrutant et formant des juniors plutôt qu’en s’appuyant sur les committers existants
En tant que programmeur intéressé mais sans expérience en C/C++, je pense qu’une série de vidéos expliquant le code en détail m’aiderait vraiment à commencer à contribuer