Industrialisation PHP

Distributions PHP

Il y a quelques semaines Cal Evans émettait l’idée que Drupal devrait forker PHP. L’idée est surprenante et audacieuse mais pas forcément aussi idiote qu'elle en a l'air au premier abord.

Tout d’abord pour ceux qui n’ont pas assistés à la table ronde « 2010 l’année des forks : et l’avenir ? Quelles sont les meilleures pratiques pour pérenniser une communauté ?» au salon Solutions Linux , rappelons ce qu’est un fork.

Je vais reprendre la définition donnée par l’AFUL dans un article récent :

« En informatique une fourche (d'après le Jargon français), ou encore un embranchement (selon Wikipédia), est un programme développé à partir des sources d'un autre. Le mot anglais original pour ce concept est le mot "fork". Une fourche a souvent pour cause une divergence profonde dans la vie d'un projet informatique qui vise à créer un logiciel. Une telle divergence dans la vie d'un projet est un élément fort, une crise, générant généralement de fortes perturbations aussi bien pour les personnes qui gèrent le projet que pour les utilisateurs du logiciel géré par le projet. On pourrait comparer la création d'une fourche au niveau informatique à un divorce pour un couple d'humains. »

Forker, si vous me permettez ce néologisme répandu, revient donc à prendre le code source d'un projet et de continuer de construire dessus sans le concours des auteurs originaux. Cela n'est bien entendu possible que grâce aux libertés accordées par les licences libres. Le monde propriétaire n'est pas concerné par ces considérations.

On voit donc que forker un projet n’est pas anodin alors pourquoi vouloir faire cet effort ?

Pourquoi forker PHP ?

Cal Evans évoque 4 raisons pour un projet comme Drupal de forker PHP :

• Amélioration du processus de développement : Il est de notoriété publique que le développement de PHP est parfois chaotique et pourrait grandement être amélioré. La communauté Drupal a prouvé qu’elle sait gérer un développement d’envergure et PHP pourrait profiter de cet expérience ;
• Adaptation du langage aux besoins de Drupal : La communauté Drupal pourrait retirer de PHP tout ce qui ne sert pas au CMS et ainsi améliorer la maintenabilité de PHP ainsi que ses performances ;
• Améliorer l’intégration entre le langage et Drupal : La communauté pourrait ajouter du code spécifique à Drupal et notamment des extensions pour une meilleure intégration des besoins du CMS dans le langage lui-même ;
• Maîtriser leur avenir : Le monde de l’Open Source est en perpétuelle évolution.  Ne dépendre que de soit peut-être un facteur de stabilité et de sérénité pour un projet.

Maintenir un fork de PHP est-il réaliste pour un projet ?

Développer un langage informatique est très différent de développer un programme.

Dans le cas de PHP, maintenir un fork nécessiterait d'avoir de solides compétences en développement C ainsi qu'une connaissance approfondie des mécanismes internes de PHP. Ce sont des compétences difficiles à trouver car longues à acquérir et en partie spécifiques à PHP. Cela ne décourage pourtant pas certains comme Robert Eisele qui a annoncé avoir forké PHP 5.3.6 pour y ajouter de nombreuses améliorations alors même que je rédigeais cet article.

Cependant, un fork ne consiste pas seulement à copier un code à un instant T et à l'adapter à ses besoins. Encore faut-il le faire vivre par la suite. Cela veut dire en maintenir la sécurité mais aussi et surtout y ajouter de nouvelles fonctionnalités.

Les trolls réguliers entre communautés montrent à quel point la compétition pour l'innovation est importante dans le domaine des langages de programmation. Pour forker avec succès PHP, il faut être en capacité de le faire évoluer de manière efficace et ce n'est pas donné à tout le monde.

Quand on regarde l'histoire des langages informatiques, il y a beaucoup d'inspiration au niveau des concepts mais rarement des forks au sens strict du terme. En préparant cet article, je n'ai en fait pas trouvé le moindre fork qui ait passé le stade de l'expérimentation anecdotique.

Il y a-t-il des alternatives aux forks ?

Les forks ne sont probablement pas la bonne réponse au problème soulevé mais au fond cela ne change pas la légitimité de la question soulevée : comment adapter le plus possible PHP aux besoins spécifiques de certains logiciels d'envergure ?

La plupart des projets de ce type proposent des suggestions pour optimiser les performances sous forme de paramétrage recommandé ou d'usage de cache en mémoire. C'est un bon début mais on est loin du compte.

Certains projets ont envisagé par le passé de remplacer les parties les plus gourmandes de leur logiciel par une extension PHP afin d'améliorer les performances. Ça a notamment été le cas de Smarty. Malheureusement, l'usage massif d'hébergements bas de gamme ne permettant pas la compilation de module tiers a tué ces initiatives. Cependant, l'idée reste intéressante et le contexte n'est plus le même. L'usage de PHP s'est professionnalisé et les plate-formes d'hébergement avec.

Des distributions de PHP

Le monde Linux a une approche particulière du développement et de la distribution des logiciels. Des développeurs développent le noyau du système, le Kernel, qui est la fondation de tout le reste mais qui en soit ne fait pas grand chose d'exploitable par le commun des mortels. D'autres développeurs prennent ensuite ce noyau, le complète de nombreux logiciels additionnels, effectuent des réglages pour optimiser tel ou tel aspects et diffusent le résultat sous forme de distributions Linux. Les plus célèbres sont probablement Red Hat, Debian ou encore Ubuntu qui est elle-même basée sur Debian.

Imaginons qu'au lieu de forker PHP un projet en propose une distribution optimisée pour ses besoins. Cela commencerait par la reprise de la dernière version de PHP éventuellement patchée pour en optimiser certains aspects, débarrassée des parties inutiles pour le projet, et compilée avec toutes les options adaptées.

Ce socle serait ensuite complété par des extensions spécifiques qui viendraient par exemple remplacer du code peu adapté à une exécution par PHP pour en optimiser les performances ou bien apporter de nouvelles  possibilités fonctionnelles.

Une fois cette distribution élaborée elle serait diffusée et maintenue par le projet lui-même.

Cela ne résout pas tous les problèmes et nécessite toujours des compétences C et une connaissance approfondie des mécanismes internes de PHP mais le périmètre sur lequel porte ces efforts est bien plus réduit. Cela permet également de profiter de la vitalité de la communauté PHP et des nouvelles versions qui sortiront.

Enfin, réduire la base de code pour en optimiser les performances revient à  réduire les possibilités offertes par le langage et donc compliquer la création d'extensions qui sont souvent la richesse des applications. La désactivation sera donc probablement une piste à privilégier.

Une approche réservée à quelques projets d'envergure

Soyons clair : cette approche n'est pas adaptée à l'immense majorité des projets PHP. Pour être en capacité de la mettre en œuvre il faut selon moi plusieurs critères.

Tout d'abord le projet doit concerner un public disposant des ressources humaines et matérielles pour déployer ces applications sur des systèmes permettant l'installation de logiciels tiers (serveurs dédiés, VPS, cloud, etc. ). Des projets comme Drupal, Magento ou encore WordPress rentrent dans cette catégorie mais en revanche un logiciel pourtant très utilisé comme phpBB me semble trop orienté amateurs, par opposition à professionnels, il n'y a pas de jugement de valeur dans mes propos.

Ensuite, il faut que le projet soit suffisamment gros et structuré pour pouvoir mettre en place une équipe spécialisée. Comme je l'ai dit précédemment, ce n'est pas une mince affaire. Il s'agit véritablement d'un projet dans le projet.

On le voit, la liste des prétendants est courte mais pour eux les gains pourraient être importants.