Flutter est un kit de développement multiplateforme open source (sous licence BSD). Créé par Google, il a d’abord été conçu pour les applications mobiles, mais a pris du galon avec les années. On se souvient notamment que c’est Canonical qui s’était chargé de son portage sur Linux. La société l’a ensuite utilisé pour réécrire complètement l’installeur de la distribution Ubuntu.

Mais l’un des anciens développeurs du SDK, Matt Carroll, resté sous forme de contributeur externe, a annoncé récemment la création d’un fork. Pour rappel, le terme peut être traduit par « bifurcation » ou « embranchement ». Il est utilisé dans le cas où le code source d’un projet est copié pour servir de base à un nouveau projet. L’opération est extrêmement courante dans le monde du libre et alimente l’émulation autour du développement logiciel. Firefox a par exemple plusieurs forks : LibreWolf, Waterfox, Iceweasel…

Dans le cas présent, Matt Carroll a annoncé un fork de Flutter le 27 octobre, citant de vastes problèmes chez Google et une réduction continuelle de l’équipe. Le nom du nouveau projet ? Flock (sans rapport avec notre dessinateur).

Un trop grand nombre de problèmes

Matt Carroll fait une longue liste des problèmes observés sur ces dernières années. Son principal grief est une équipe de développement manquant singulièrement de personnel. Il l’estime à une cinquantaine de personnes (chiffre gelé en 2023), alors que le nombre de développeurs utilisant Flutter serait d’un million, une estimation basse et conservatrice selon lui. Le ratio serait alors d’un membre de l’équipe pour 20 000 développeurs, ce qui ne peut pas fonctionner, d’après Matt Carroll.

Il cite plusieurs exemples, dont le temps de traitement des tickets de support. Il affirme qu’il peut s’écouler parfois plusieurs années entre la création d’un ticket et le moment où l’équipe s’en empare pour l’examiner. Or, avec le temps, les informations qui avaient servi à le créer ont peut-être été perdues. Le développeur a pu passer à autre chose et oublier le contexte du problème signalé.

« D'après mon expérience, lorsque cela m'arrive, j'ai cessé depuis longtemps de travailler avec le client à l'origine du problème initial. J'ai écrit des centaines de milliers de lignes de code depuis lors et, souvent, je ne me souviens même pas d'avoir déposé le problème, sans parler des détails obscurs liés au problème initial. L'équipe ne peut pas corriger le bug sans mes informations, et cela fait trop longtemps que je ne lui en ai pas fournies. Le bug est donc enterré et sera redécouvert par un futur développeur », explique Matt Carroll.

L’ancien employé de Google cite également les changements de priorités dans l’entreprise, avec des yeux largement tournés vers l’intelligence artificielle. Google vient d’ailleurs de mettre en avant que plus d’un quart du nouveau code écrit par ses développeurs l’a été par une IA générative. Les plateformes desktop ne sont ainsi plus considérées comme des priorités et trois des six plateformes sont en mode maintenance. Le desktop est selon Carroll le plus grand gâchis de Flutter. Certains des bugs non corrigés étaient suffisamment importants pour que les clients changent de crèmerie.

Il est vrai que les questions autour de Flutter commençaient à s’accumuler. La dernière Google I/O en mai a renforcé les inquiétudes. De nouvelles versions avaient bien été proposées pour Flutter (3.22) et Dart (3.4), mais l’arrivée de Kotlin Multiplatform les a éclipsés. Plusieurs médias avaient noté ce changement, dont DevClass. En outre, l’ancien directeur de l’équipe Flutter, Tim Sneath (ancien transfuge de Microsoft), est parti chez Apple en juin 2023.

Le choix du fork

Matt Carroll indique que la question d’une coopération massive avec des développeurs externes aurait pu être envisagée. Le problème est cependant le même, car l’afflux des participations aurait été géré par la même équipe qui manque actuellement de main d’œuvre pour s’occuper des tickets du support. Or, la révision du code prend du temps. En outre, de nombreux développeurs auraient trouvé la communication avec l’équipe Flutter « frustrante, voire impossible ».

Que propose-t-il ? Flock, un fork de Flutter imaginé comme un catalyseur. Il décrit en effet le projet comme un « Flutter+ », non comme un remplaçant. Il espère attirer les contributions pour faire de Flock un outil dont les bugs seront corrigés rapidement, tout comme l’ajout de nouvelles fonctions.

« En d'autres termes, nous ne voulons pas, ou avons l'intention, de forker la communauté Flutter. Flock restera constamment à jour avec Flutter. Flock ajoutera d'importantes corrections de bugs et des fonctionnalités populaires de la communauté, que l'équipe de Flutter ne peut pas ou ne veut pas implémenter », indique Matt Carroll.

Dans les grandes lignes, chaque nouvelle version de Flutter verra ses nouveautés portées vers Flock. Ce dernier ira dans le sens que sa communauté de développeurs estimera la plus logique, s’occupant d’abord de tous les bugs en attente, tout en partageant le code correcteur avec l’équipe de Flutter, qui sera alors libre de l’intégrer ou non.

Sa priorité pour l’instant est de créer un miroir de Flutter pour refléter automatiquement les branches master, beta et stable. Il faudra ensuite que Flock puisse construire le moteur d’exécution. Matt Carroll invite les développeurs à participer et à tester leurs applications sur Flock. Pour l’instant, puisqu’il s’agira d’une copie miroir, elles devraient fonctionner sans modification.

Des réactions mitigées

Que ce soit sur Hacker News ou Reddit, les réactions sont en majorité négatives. Beaucoup estiment que les problèmes avancés par Matt Carroll sont réels et sérieux. Cependant, la plupart pensent que dans ce cas précis, la création d’un fork va diviser les ressources et ne servira pas.

« Mais je suis sceptique quant à sa suggestion d'accueillir de nouveaux changements dans un fork de Flutter et ainsi gagner en vitesse de développement. Cela nécessiterait des personnes qui souhaitent réellement travailler sur de nouvelles fonctionnalités. Je doute que ces personnes existent. Du moins, qu'elles existent en nombre suffisant pour qu'un fork soit plus rapide – en termes de fonctionnalités – que Google lui-même », estime par exemple l’un d’entre eux sur Reddit.

En revanche, sur X, l’annonce a créé plus d’engouement, Matt Carroll ayant répondu à de nombreuses questions, certaines très concrètes. Par exemple, Remi Rousselet se demandait hier comment gérer les paquets si Flock devient aussi populaire que Flutter : faudra-t-il que leurs auteurs supportent systématiquement les deux ? Matt Carroll lui a répondu que la conduite serait de recommander Flock pour les applications et Flutter pour les paquets. À un autre, il a répondu qu’en cas de conflit d’approche sur une fonction, la version Flock serait supprimée.