"Flock" en tant que nouveau "Flutter+" : Fork du kit de développement logiciel d'interface utilisateur open-source Flutter

Pour aider à étendre la main d'œuvre de Flutter et accélérer le développement

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 :

Conclusion

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