Je caricature quelque peu, car il y a des exceptions, comme Pierre Joye qui participe au développement de PHP depuis très longtemps, mais est pour autant l’un des meneurs du camp progressiste.
Dieu, aka Rasmus Lerdorf, est également une autre exception, car il n’a pas clairement choisi son camp et à même en règle générale un point de vue différent de celui des deux camps, pour le pire ou le meilleur.
Fondamentalement, PHP est donc le résultat d’un affrontement permanent entre ces deux camps qui prend la forme de discussions sans fin dans un langage plus ou moins fleuri ou imagé en fonction de l’humeur des participants sur IRC, les listes de diffusion ou Twitter.
Depuis l’abandon du développement de PHP 6 illustrant les problèmes posés par ce mode de fonctionnement, les progressistes sont parvenus à prendre l’initiative et ont donc actuellement l’avantage sur les traditionalistes.
C’est donc à ses membres que nous devons la quasi-totalité des avancés techniques intégrés au langage depuis sa version 5.3.
Pour autant, leur avantage est très ténu et n’est pas suffisant pour leur laisser réellement les coudées franches.
Chaque suggestion d’évolution est donc malgré tout âprement discutée, même si les progressistes sont parvenus à mettre en place un système de RFC et de votes censé simplifier la prise de décision pour rendre plus transparent le développement du langage aux yeux de ses utilisateurs.
De même, ils sont parvenus à accélérer le développement de PHP, ses nouvelles versions se suivant maintenant à un rythme beaucoup plus soutenu que par le passé.
Pour autant, l’équilibre entre les deux camps est si fragile qu’il arrive que les traditionalistes disposent de suffisamment de poids pour bloquer le développement de fonctionnalités comme celle évoquée par Éric.
Pour remédier à cela, une solution simple serait d’augmenter le nombre de progressistes ce qui leur permettrait de disposer d’un réservoir de votes plus importants et donc d’emporter quasi systématiquement les élections relatives aux RFC.
Malheureusement, il n’est pas évident de s’intégrer à la communauté des développeurs de PHP.
En effet, même si des efforts sont actuellement faits pour faciliter l’intégration, le manque de documentation et d’informations ainsi que l’ambiance très particulière qui règne au sein de la communauté et son côté très « fermé » (je vous laisse deviner le camp qui fait de l’obstruction sous diverses formes à l’arrivée de nouveaux contributeurs) font qu’il faut vraiment en vouloir pour parvenir à participer activement et significativement au développement du langage.
De plus, le suivi des discussions des développeurs sur IRC ainsi que celui des diverses listes de diffusion ainsi que l’analyse des RFC et des modifications effectuées quotidiennement sur le code demande un travail relativement important pour être effectué correctement.
Pour avoir fait la chronique des discussions ayant lieu sur internals@, la principale liste de diffusion du langage, pendant pas mal de temps avant de passer le flambeau à Pascal Martin, je suis très bien placé pour savoir le travail que cela demande, d’autant que le « bruit » peut y être très important et perturbe donc l’extraction des informations essentielles.
De plus, les « disputes » ayant lieu publiquement via Twitter ou d’autres canaux entre les deux camps n’encouragent pas vraiment un éventuel contributeur à s’investir.
Le serpent se mord donc la queue, puisque pour que les progressistes puissent réellement prendre la main, il faudrait que la communauté soit plus attrayante et ouverte, mais pour cela, il faudrait que le camp des traditionalistes devienne vraiment minoritaire, ce qui implique l’intégration de sang neuf.
Et le problème se complique encore lorsque l’on intègre Zend dans l’équation.
Zend est en effet la société à l’origine du Zend Engine, la machine virtuelle qui interprète et exécute le code PHP et son modèle économique repose intégralement sur le langage.
Cette société a donc tout intérêt à le faire évoluer, mais uniquement si cela ne va pas à l’encontre de ses intérêts économiques.
Il a donc été très difficile de faire adopter le principe des RFC et des votes à Zend à l’époque, car cela impliquait pour elle de perdre une grande partie du contrôle qu’elle avait sur le développement du langage, ses membres étant historiquement plus traditionalistes que progressistes.
Pour autant, depuis, Zend n’avait que très peu participé aux différents débats ayant agité la communauté des développeurs, du moins jusqu’à maintenant.
Il y a quelques semaines, Zeev a en effet annoncé que Zend allait rendre public le code du « Zend Optimiser + » en vue de son intégration dans PHP en lieu et place de APC dont le développement présente beaucoup de difficulté et ne parvient pas à suivre le même rythme que celui du langage.
We're looking into open-sourcing Zend Optimizer+ and including it in PHP 5.5.We're still pre-RFC, pre-cleanups - but it looks plausible!
— Zeev Suraski (@zeevs) 25 janvier 2013
Sur le moment, j’ai pensé que c’était une très bonne initiative et que PHP avait tout à y gagner, mais je me suis tout de même demandé le prix que devrait payer la communauté pour profiter de ce « cadeau » ainsi que l'objectif poursuivi par Zend.
J’ai très vite compris.
En effet, très bizarrement et pour une fois, la plupart sinon la totalité des traditionalistes sont favorables à une intégration très rapide du code de Zend dans PHP, quitte à ne pas prendre toutes les précautions nécessaires et ne pas suivre les procédures qui ont été mises en place dernièrement par le camp progressiste.
Zend semble donc se servir de son « cadeau » à la communauté comme d’un cheval de Troie pour reprendre la main sur le développement du langage.
Évidemment, les progressistes font leur possible pour limiter les dégâts tout en soutenant l’initiative, car même s’ils sont enthousiastes à son propos, ils ne veulent pas que les choses soient faites n’importe comment et surtout ils ne veulent pas qu'elle permette à Zend de verrouiller le développement futur du langage.
Ils souhaitent donc que la communauté dispose du temps nécessaire pour prendre connaissance du code et de ses impacts techniques avant qu’une intégration complète soit effectuée.
À contrario, Zend, par l’entremise de Zeev, fait tout son possible pour que cette intégration se fasse le plus rapidement et le plus complètement possible.
Dans un tel contexte, il faut donc vraiment du courage pour vouloir devenir un contributeur, mais paradoxalement, je pense que l'entrée de nouveaux membres dans la communauté de ses développeurs est la seule façon pour le langage de ne pas tomber plus ou moins sous la coupe d'intérêts économiques et de continuer à évoluer comme il le fait actuellement, voir mieux encore.
6 réactions
1 De Wallace - 14/03/2013, 00:56
merci pour ces billets très instructifs et qui permettent de suivre l'évolution de php de façon distante.
2 De desfrenes - 14/03/2013, 10:31
Tout ça n'est pas bien rassurant. Pour parler de mon cas, je continue à m'intéresser à PHP car de toute façon nous avons des applis en place qui demanderont des évolutions et de la maintenance encore longtemps, mais nous avons déjà changer -avec bonheur!- de stack pour les nouveaux développements.
3 De jprivard - 14/03/2013, 12:17
J'avais eu vent de quelques histoires, mais cet excellent billet a pu confirmer (et même infirmer dans quelques cas) quelques unes de ces histoires entendues. À la lecture de ce billet par contre, je me demandais si tu (pardonnes mon utilisation du familier) participes ou non à la communauté ? Et j'aimerais bien savoir quelle est ta vision, aussi subjective soit-elle) du futur de PHP ?
4 De mageekguy - 14/03/2013, 12:47
@jprivard : Je suis de très prés le développement du langage, intervient parfois dans les débats et discutent avec certain des contributeurs très régulièrement de pas mal de choses autant technique que philosophique ou politique concernant le langage.
Je suis également les discussions sur différentes listes de diffusion ainsi que ce qu'il se dit sur IRC.
De plus, il m'arrive de demander des informations ou de lancer un débat (parfois sans même le vouloir…) à propos de contraintes imposées par le langage (j'ai le souvenir de vives discussions concernant l'absence du support de
__isset()
dans PHP 5.0, par exemple).Techniquement, je fais parfois quelques propositions, fait des rapports de bug et j'écris également des tests unitaires, en général lorsque je détecte un bug.
J'aimerais m'investir plus mais je manque de temps pour cela, car entre la famille et mes projets annexes, je n'ai pas de marges de manœuvre.
En conséquence, je suis plus journaliste d'investigation que contributeur actuellement, même si j'estime apporter d'une certaine manière ma pierre à l'édifice.
Quand à ma vision, j'ai déjà répondu il y a pas mal de temps et honnêtement, je ne me suis pas reposé sérieusement la question depuis.
5 De Amaury Bouchard - 25/03/2013, 16:04
Pour avoir fait une proposition d'évolution au langage l'été dernier (http://news.php.net/php.internals/6...), j'ai pu me frotter un peu à tout ça. Et les choses me semblent - d'après ce que j'en ai vu - légèrement différentes.
Au sujet de l'intégration de Zend Optimizer dans PHP, il semblerait que cela ait été largement approuvé pour la simple raison qu'APC est une truc énorme, très difficile à maintenir et à faire évoluer. Pour preuve les problèmes que PHP 5.4 a rencontré avec APC, et les problèmes qui se dessinaient pour PHP 5.5.
Pour le reste, malgré le fait que je propose une fonctionnalité plutôt innovante, je me suis senti plus proche de ce que tu appelles les "traditionalistes", lors de discussions sur la mailing-list. Un certain nombre de "progressistes" semblent vouloir faire *avancer* le langage, à tout prix, par tous les moyens possibles, même si on ne s'accorde pas sur la définition de l'avancement.
On en arrive parfois à des situations bizarres, comme le fait d'avoir un langage qui intègre des notions assez pointues (générateurs, traits) mais qui ne connait pas les énumérations.
Anthony Ferrara a bien essayé de pousser pour que soit définie une "vision" du langage (http://news.php.net/php.internals/6...). Mais je pense qu'il s'y est mal pris. En fait, je pense que la réponse de Rasmus était la bonne :
«The vision has been the same for years. A general purpose scripting
language with a focus on web development.»
Et cela reflète la vision de Rasmus. L'informatique est un outil, pas une fin en soi.
Concernant la RFC commentée par Éric, je suis pleinement d'accord avec son refus. Cette proposition apportait une syntaxe (provenant du C#) qui me semblait excessivement lourde par rapport au besoin de base. C'est un avis personnel.
Mais honnêtement, quand on commence à vouloir ajouter un mot-clé "read-only", il y a un malaise : Pourquoi ajouter un nouveau mot-clé, alors qu'il existe "private" ? Pourquoi vouloir limiter la visibilité à seulement 2 états (visible ou non), alors que le "protected" a quand même une signification forte ?
Et je ne dis pas ça seulement parce que ma proposition recoupait celle-ci, mais en étant plus simple pour les cas usuels. Je pense que les deux propositions auraient pu être menées conjointement, elles étaient complémentaires. En poussant un peu, je dirais même que la RFC sur les accesseurs aurait peut-être eu plus de chances d'être acceptée si elle avait intégré mes propositions, car sa syntaxe aurait été bien plus simple...
6 De Amaury Bouchard - 26/03/2013, 09:28
Correction : Quand j'ai écrit «Pourquoi ajouter un nouveau mot-clé ("read-only"), alors qu'il existe "private" ?», je voulais évidemment dire «Pourquoi ajouter un nouveau mot-clé ("read-only"), alors qu'il existe "const" ?»