Mission, vision, stratégie, valeurs

Mission

Apporter l'Open Source au monde de l'entreprise.

Faire en sorte que les entreprises obtiennent de PostgreSQL et de son écosystème libre la même confiance, la même structure de responsabilité, qu'elles n'obtiennent aujourd'hui que d'un fournisseur propriétaire — sans l'enfermement propriétaire, ni le coût total de possession qu'il entraîne. Les entreprises n'achètent que rarement du propriétaire pour la qualité d'ingénierie ; elles achètent le contrat qui évite à la personne qui a fait le choix de porter le blâme.

Vision

Faire le pont entre deux façons de travailler : la manière dont l’entreprise a l’habitude de fonctionner — sous-traitance, régie ou forfait, licences, lignes de support — et la manière dont l’open source fonctionne réellement. Ce modèle a déjà fait ses preuves : il produit un meilleur résultat sur tout ce qui compte — qualité, ingénierie, tenue en production, adéquation au besoin. PostgreSQL en est la preuve la plus nette : sur le classement DB-Engines lui-même, c’est le seul système du top 4 encore en croissance, quand Oracle, MySQL et SQL Server perdent tous du terrain — et selon la Stack Overflow Developer Survey, c’est « la technologie la plus désirée et la plus admirée de sa catégorie », en tête des deux classements depuis 2023.

L’open source a un angle mort structurel : ce qu’aucun bénévole n’a envie de faire reste un manque, quel que soit le projet. Dans la communauté PostgreSQL aujourd’hui, ce manque se situe du côté de l’archivage et, plus largement, de l’outillage d’architecture de production qui entoure le cœur du moteur — le développement du cœur de PostgreSQL, lui, ne manque ni de financement ni de contributeurs ; ce qui l’entoure en production, si. Prenez la haute disponibilité et le disaster recovery : l’outillage actuel les sépare selon une ligne technique — la HA d’un côté, le DR regroupé avec les sauvegardes de l’autre — alors que ce que veulent les utilisateurs, c’est la HA et le DR ensemble, et les sauvegardes comme sujet à part. La prochaine version de pg_auto_failover corrige exactement cela.

L’écosystème que je maintiens est pensé pour aider sur les architectures en production (pg_auto_failover, pgextwlist, pginstall, pgcopydb) et sur la migration vers PostgreSQL (pgloader, pgcopydb).

Stratégie

1. 1

   Support Open Source, priorités utilisateurs

   Le développement suit les besoins réels de production, arbitrés par une vision technique cohérente.

2. 2

   Autonomisation par la transmission

   Le livre et les cours The Art of PostgreSQL donnent aux équipes les moyens de comprendre, pas seulement d'utiliser.

3. 3

   Un modèle économique soutenable

   Pensé pour durer, sans dépendre d'une levée de fonds ni d'un rachat.

4. 4

   Un prototype vaut mieux qu'un document de conception

   On tranche sur du code qui tourne, pas sur des spécifications.

Valeurs

1. 01

   Autonomie

2. 02

   Excellence technique

3. 03

   Respect des individus plutôt que des process

4. 04

   Service aux utilisateurs

5. 05

   Technique au service de l'humain, pas l'inverse

6. 06

   Décisions concrètes, sans jeux politiques de comité

7. 07

   Transfert de compétences

8. 08

   Amélioration continue

9. 09

   Itérations rapides