Avec l'augmentation des développeurs utilisant Flutter, un nouveau fork du kit de développement open-source est née, appélé "Flock". La raison principale étant de répondre au problème de main d'oeuvre de l'équipe Flutter. Pourquoi ne pas travailler directement avec l'équipe Flutter ? Comment la communauté Flutter peut aider au développement de Flock ? Voici la réponse à ces questions et la présentation de Flock.Flutter est un kit de développement logiciel d' interface utilisateur open-source créé par Google. Il peut être utilisé pour développer des applications multiplateformes à partir d'une base de code unique pour le web, Fuchsia, Android, iOS, Linux, macOS et Windows. Flutter fournit ses applications avec son propre moteur de rendu qui transmet directement les données des pixels à l'écran, contrairement à de nombreux autres frameworks d' interface utilisateur. Le contrôle par Flutter de son pipeline de rendu simplifie la prise en charge multiplateforme, car un code d'interface utilisateur identique peut être utilisé pour toutes les plateformes cibles.
Selon une enquête menée auprès des développeurs en 2021 par le site de statistiques Statista, Flutter serait devenu le SDK mobile multiplateforme le plus populaire avec 42 % des développeurs de logiciels utilisant Flutter. Dans l'ensemble, environ un tiers des développeurs mobiles utilisaient des technologies ou des SDK multiplateformes ; le reste des développeurs mobiles utilisent des outils natifs. Si Flutter possède également des faiblesses, ses avantages semblaient l'emporter sur ses inconvénients.
Au fil des ans, Flutter a attiré des millions de développeurs qui ont créé des interfaces utilisateur sur toutes les plateformes. Flutter a d'abord été une boîte à outils d'interface utilisateur pour mobile - iOS et Android, uniquement. Ensuite, Flutter a ajouté la prise en charge du web. Enfin, Flutter s'est étendu à Mac, Windows et Linux. Dans le cadre de cette expansion massive de la portée et de la responsabilité, l'équipe de Flutter n'a augmenté sa taille que de façon marginale. Afin d'augmenter la main d'œuvre disponible pour Flutter et d'accélérer le développement, une nouvelle branche (fork) de Flutter a été créée, appelée Flock.
La pénurie de main d'œuvre de Flutter
Voici quelques calculs pour apprécier la pénurie de main d'œuvre de l'équipe Flutter. Combien y a-t-il de développeurs Flutter dans le monde aujourd'hui ? Ils seraient de l'ordre de 1 000 000. Le chiffre réel est probablement plus élevé, mais un million devrait être raisonnablement conservateur. Quelle est la taille de l'équipe Flutter aujourd'hui ? Google ne publie pas cette information, mais l'équipe compterait environ 50 personnes.
Cela signifie que 50 personnes répondent aux besoins de 1 000 000 de personnes. En faisant un peu de division, cela signifie que chaque membre de l'équipe Flutter est responsable des besoins de 20 000 développeurs Flutter ! Ce ratio est clairement irréalisable pour un semblant d'assistance à la clientèle.
Une pénurie de main-d'œuvre peut toujours être résolue par l'embauche. Cependant, en raison de problèmes à l'échelle de l'entreprise Google, l'effectif de l'équipe Flutter a été gelé vers 2023, puis, plus tôt en 2024, avec un petit nombre de licenciements. Il semble que l'équipe soit en train de s'agrandir à nouveau, par le biais de l'externalisation, mais il est peu probable que l'équipe Flutter double ou quadruple sa taille de sitôt.
Pour ne rien arranger, le recentrage de l'entreprise Google sur l'IA a conduit l'équipe Flutter à dé-prioriser toutes les plateformes de bureau. À l'heure actuelle, l'équipe Flutter est en mode maintenance pour 3 des 6 plateformes prises en charge. L'ordinateur de bureau est probablement la plus grande valeur inexploitée pour Flutter, mais il est maintenant presque stagnant.
Le coût d'une main-d'œuvre limitée
Une main d'œuvre limitée a un coût important pour une boîte à outils qui a rapidement élargi sa base d'utilisateurs, ainsi que son champ d'application global. Avec si peu de développeurs pour travailler sur les tickets, de nombreux tickets traînent dans le carnet de commandes. Ils peuvent facilement traîner pendant des années, si tant est qu'ils soient traités.
Lorsqu'un membre de l'équipe Flutter commence à examiner un ticket, celui-ci peut dater de plusieurs années. À ce moment-là, le développeur de l'équipe Flutter demande généralement des informations supplémentaires à la personne qui a déposé le ticket. Le problème est que : souvent le développeur a changé de projet ou a déjà travaillé sur des centaines de milliers de lignes de code, et qu'il ne se souvient plus des détails du problème. L'équipe de Flutter ne pouvant corriger le bogue sans ces informations, le bogue y restera et sera redécouvert par un futur développeur.
Le temps n'est pas seulement un problème pour trouver les causes profondes des bogues et les corriger. C'est aussi un problème majeur pour le produit. Imaginez que vous soyez le directeur de l'ingénierie ou le directeur technique d'une entreprise dont la prochaine version est bloquée par un bug de Flutter. Que faites-vous si l'équipe ne travaille pas sur ce bug pendant deux ans ? Eh bien, s'il s'agit d'un bogue grave pour votre entreprise, vous arrêtez d'utiliser Flutter. Vous n'avez pas le choix. Vous devez continuer à avancer. Votre équipe ne sait pas comment travailler sur le framework Flutter, et l'équipe du framework Flutter ne répond pas, ou du moins ne s'engage pas du tout à corriger le problème. Oh bien sûr, vous ne pouvez plus utiliser Flutter. Flutter ne survivra pas si ce genre d'expériences devient courant.
La communauté Flutter peut aider au travail
Flutter possède deux qualités très précieuses. Tout d'abord, il est open source, donc n'importe quel développeur peut voir comment n'importe quelle partie de Flutter est implémentée, et peut même la modifier. Deuxièmement, le framework Flutter est écrit dans le même langage que les applications Flutter. Grâce à ces deux qualités, les développeurs d'applications Flutter expérimentés et les développeurs de paquets peuvent contribuer au framework Flutter.
Combien y a-t-il de développeurs Flutter dans le monde aujourd'hui qui sont capables de contribuer de manière productive au framework Flutter ? Au moins dans les environ de 1 000. En d'autres termes, il y a au moins 1 000 développeurs Flutter dans le monde qui pourraient être embauchés dans l'équipe Flutter, si l'équipe voulait embaucher autant de développeurs.
En terme de ration, si tous les contributeurs du framework Flutter dans le monde contribuaient régulièrement à Flutter, ce ratio de 1 pour 20 000 tomberait à 1 pour 1 000. C'est toujours un ratio important, mais il est bien meilleur qu'aujourd'hui. De plus, comme de plus en plus de contributeurs externes se sentent à l'aise pour soumettre des correctifs et des fonctionnalités à Flutter, ils auront tendance à aider à former d'autres personnes à faire de même. Ainsi, le ratio de support continuera d'évoluer dans une meilleure direction.
Pourquoi ne pas travailler directement avec l'équipe Flutter ?
Si l'augmentation des contributions externes est la voie vers un meilleur monde Flutter, alors pourquoi forker Flutter alors que tout le monde pourrait simplement travailler directement avec l'équipe Flutter ? Il est tentant de mettre en place un effort concerté pour contribuer directement à Flutter. Après tout, l'équipe de Flutter vante régulièrement le nombre de contributions externes qu'elle intègre à chaque version. Selon l'effort de relations publiques de Flutter, ils adoreraient toutes ces contributions externes !
Malheureusement, la réalité est tout autre lorsqu'on essaie de travailler avec l'équipe Flutter. Si certains développeurs ont réussi à travailler avec l'équipe Flutter, beaucoup d'autres ont trouvé cela frustrant, voire impossible. Il y a, sans aucun doute, un certain nombre de facteurs qui contribuent à ce résultat. Chaque développeur rencontrera des problèmes différents. En voici quelques-uns :
- Travail de révision limité :
- Les développeurs qui n'ont pas assez de temps pour écrire du code sont les mêmes que ceux qui sont chargés de réviser les contributions. Par conséquent, la révision ou les mises à jour peuvent prendre beaucoup de temps.
- Le manque de temps semble également se prêter à des conversations de révision litigieuses.
- Tout prend une éternité, et il semble toujours s'agir de détails non critiques.
- Monoculture de la communication - la plupart des membres de l'équipe semblent s'attendre à une certaine façon de communiquer, qui ne correspond pas à la diversité des personnalités dans le monde. Ainsi, certaines personnes ont beaucoup de mal à s'adapter à des conversations simples et rapides.
Le résultat des problèmes mentionnés ci-dessus, et probablement d'autres qui ne sont pas listés, est que le nombre total de personnes ayant contribué au framework Flutter est actuellement inférieur à 1500. Ce chiffre inclut les personnes qui sont passées une fois pour corriger une faute de frappe dans un document Dart et qui n'ont plus jamais contribué. Ce n'est pas le nombre de contributeurs réguliers qui apportent une valeur ajoutée significative.
Quelle que soit votre expérience des contributions à Flutter, il faut se demander pourquoi une équipe qui adore les contributions externes n'a réussi à fusionner que les contributions de 1 500 développeurs sur une période de près de dix ans. Une piste serait que le message invitant de l'équipe des relations publiques ne correspond pas à l'expérience de la mise en place d'un changement à travers les politiques de l'équipe, la disponibilité des développeurs et la culture technique.
Les seules personnes qui peuvent changer cette réalité sont les membres de l'organisation Flutter. Cependant, la plupart de ces personnes ne pensent pas que cela soit un problème, un certain nombre d'entre eux l'ont exprimé directement. Il y a un certain nombre d'angles morts importants pour l'équipe Flutter, qui tournent principalement autour du fait que les membres de l'équipe n'ont jamais été responsables de la livraison routinière de fonctionnalités et de corrections d'applications basées sur Flutter.
En d'autres termes, il y a des angles morts parce que les membres de l'équipe Flutter n'utilisent pas réellement Flutter. Ainsi, l'urgence de nombreux problèmes n'est pas appréciée, pas plus que l'urgence et le coût en temps associés à la soumission de correctifs directement à Flutter en tant que contributeur externe. C'est pourquoi des développeurs Flutter ont décidé de forker Flutter pour résoudre le problème de la main d'œuvre.
Matt Carroll, un des développeurs à l'origine de l'idée, présente Flock :
Envoyé par Matt Carroll
Présentation de Flock
Notre version de Flutter s'appelle Flock. Nous décrivons Flock comme "Flutter+". En d'autres termes, nous ne voulons pas, ou n'avons pas 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 ou ne veut pas implémenter.
En forkant Flutter, nous décidons de ce qui sera fusionné. Nous n'abaisserons pas la barre de qualité, mais en contrôlant les décisions de fusion, nous gagnons les opportunités suivantes :
Au fur et à mesure que Flock livre des corrections de bugs et des fonctionnalités importantes, l'équipe Flutter peut alors choisir de les ajouter à Flutter, selon son calendrier. La communauté ne sera plus limitée par la disponibilité de l'équipe Flutter, et n'aura plus besoin de supplier l'équipe Flutter d'accepter un changement. L'équipe Flutter peut utiliser les solutions de Flock, ou non, mais tous les utilisateurs de Flock y auront accès, éliminant ainsi l'urgence et le désespoir de votre entreprise et de votre équipe.
Comment s'impliquer
Flock, comme son nom l'indique, n'ira pas plus loin que la communauté qui le soutient. Nous aimerions que vous vous impliquiez.
Flock ensemble
Faisons passer Flutter à la vitesse supérieure et aidons-le à devenir la boîte à outils universelle d'interface utilisateur qu'il aurait dû être. Flutter a le potentiel de surpasser toutes les alternatives du marché. Mais il a besoin que la communauté s'unisse pour l'aider à y parvenir. C'est ce qu'il faut faire !
Notre version de Flutter s'appelle Flock. Nous décrivons Flock comme "Flutter+". En d'autres termes, nous ne voulons pas, ou n'avons pas 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 ou ne veut pas implémenter.
En forkant Flutter, nous décidons de ce qui sera fusionné. Nous n'abaisserons pas la barre de qualité, mais en contrôlant les décisions de fusion, nous gagnons les opportunités suivantes :
- Recruter une équipe de révision des PR bien plus importante que celle de Flutter. Cela signifie des délais de révision plus courts.
- Recruter des réviseurs PR qui sont prêts à faciliter les contributions, au lieu de simplement les tolérer. Cela permet de soutenir un plus grand nombre de contributeurs.
- Optimiser les politiques. Par exemple, ne pas exiger aveuglément des documents de conception et des conférences téléphoniques lorsqu'ils ne contribuent pas de manière substantielle à l'efficacité de la tâche à accomplir.
- Utiliser les succès des contributions pour promouvoir socialement plus de contributions.
- Nous sommes tous des utilisateurs de Flutter - exploitez les relations de l'équipe et de l'entreprise pour identifier les priorités du marché.
Au fur et à mesure que Flock livre des corrections de bugs et des fonctionnalités importantes, l'équipe Flutter peut alors choisir de les ajouter à Flutter, selon son calendrier. La communauté ne sera plus limitée par la disponibilité de l'équipe Flutter, et n'aura plus besoin de supplier l'équipe Flutter d'accepter un changement. L'équipe Flutter peut utiliser les solutions de Flock, ou non, mais tous les utilisateurs de Flock y auront accès, éliminant ainsi l'urgence et le désespoir de votre entreprise et de votre équipe.
Comment s'impliquer
Flock, comme son nom l'indique, n'ira pas plus loin que la communauté qui le soutient. Nous aimerions que vous vous impliquiez.
- Alpha testeur pour le fork
La première étape de Flock est de créer un miroir de Flutter. Cela signifie que les branches master, beta et stable sont automatiquement mises en miroir, et que toutes les étiquettes de version sont répliquées. De plus, une fois le framework miroité, Flock devra construire et télécharger automatiquement le moteur, et rendre ces binaires disponibles aux utilisateurs de Flock.
Pendant que nous travaillons sur le processus de création de miroirs, il serait très utile que vous essayiez de créer vos applications avec Flock. Vous ne devriez pas voir de différence entre Flock et Flutter, et vous pouvez configurer Flock avec une petite configuration de Flutter Version Manager (FVM). - Devenir réviseur
Flock a besoin de recruter des dizaines de réviseurs. Les réviseurs sont chargés d'appliquer une barre de qualité similaire à celle de Flutter. Cela inclut l'exigence de noms de classes, de méthodes et de propriétés descriptifs, de docs Dart efficaces et de tests appropriés.
Mais nous voulons que les évaluateurs aillent encore plus loin. Nous ne voulons pas seulement tolérer les contributions, nous voulons les faciliter. Beaucoup d'entre nous ont déjà eu l'occasion d'amener un PR à 90% jusqu'à la ligne d'arrivée et de voir un réviseur de l'équipe Flutter déclaré qu'il ne peut pas être fusionné tant que nous ne faisons pas quelque chose que nous ne savons pas faire. C'est une expérience terrible, et nous voulons l'éviter avec Flock.
Nous voulons des réviseurs Flock qui sont prêts à intervenir et à aider un contributeur à atteindre les 10 % finaux du PR. Cela ne signifie pas que les contributeurs peuvent être paresseux. Mais si un contributeur a fait tout ce qu'il savait faire et que le rapport est presque terminé, nous voulons que le réviseur intervienne et donne des instructions pour les derniers 10 %. C'est ainsi que nous formons les contributeurs et que nous nous assurons que le prochain PR est complet à 100 %. - Devenir un leader
Maintenir et étendre un fork de Flutter à long terme nécessite un certain nombre d'experts qui dirigent des domaines spécifiques du projet. Par exemple, j'ai décidé de devenir le directeur de Flock, ainsi que le responsable du framework. Jesse Ezell a pris la direction du moteur.
Nous aimerions recruter un responsable de l'outil Flutter, qui dirigera les extensions de l'outil CLI de Flutter. Nous aimerions également répartir les responsabilités du moteur avec un responsable par plateforme : Android, iOS, Mac, Windows, Linux.
Flock ensemble
Faisons passer Flutter à la vitesse supérieure et aidons-le à devenir la boîte à outils universelle d'interface utilisateur qu'il aurait dû être. Flutter a le potentiel de surpasser toutes les alternatives du marché. Mais il a besoin que la communauté s'unisse pour l'aider à y parvenir. C'est ce qu'il faut faire !
Avec le fork "Flock", les problèmes de main d'oeuvre pour le développement du framework Flutter devraient se réduire, voire se résoudre avec le temps. Cette initiative arrive à un moment où certains membres de la communauté de Flutter s'inquiétaient pour le framework. Par exemple, à la suite de licenciements parmi les équipes Flutter et Dart, un développeur s'est questionné : Flutter est-il sur le point de disparaître ? Flutter remplit-il toujours son rôle chez Google ?
Il avait notamment déclaré : "Cela suggère une hiérarchisation des investissements et une stratégie de désinvestissement progressif. À la lumière de ces événements récents et de la tendance émergente, je me trouve de plus en plus incertain quant à l'avenir de Flutter." Cette initiative devrait donc rassurer en partie la communauté Flutter.
Source : "We're forking Flutter. This is why."
Et vous ?
Pensez-vous que ce fork de Flutter est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
Google publie Flutter 3.7 et évoque l'avenir du framework de développement d'applications, cette version améliore le support de Material You, les performances et la gestion de la mémoire Google licencie du personnel des équipes Flutter, Dart et Python. L'entreprise aurait licencié toute l'équipe Python aux États-Unis pour la remplacer par une « main-d'œuvre moins chère » à Munich L'Open Source serait en difficulté et ce n'est pas la faute des grandes entreprises technologiques, d'après Jan Kammerath 
