Il y’a un peu plus d’une année que Microsoft a annoncé le passage d’une grande partie du framework .NET à l’open source. Une question qu’il est pertinent de se poser depuis lors est celle de savoir comment il se porte. La communauté a-t-elle adopté .NET comme le souhaiterait Microsoft ? À l’aide de l’outil Microsoft Power BI, Matt Warren a effectué une analyse de trois des projets les plus significatifs, mais aussi les plus actifs de l’écosystème .NET à savoir Roslyn, CoreCLR et CoreFX. Pour rappel, Roslyn est la plateforme de compilation de .NET comprenant les compilateurs pour C# (open source) et Visual Basic ainsi qu’une performante API d’analyse de codes sources. CoreCLR est composé du noyau de la plateforme d’exécution de .NET appelé CoreCLR, de la bibliothèque de base appelée mscorlib, le ramasse-miettes, un compilateur JIT, les types de données de base ainsi que beaucoup de classes de bas niveau. CoreFX lui, est composé des bibliothèques fondamentales du noyau de .NET et comprend les classes de gestion des collections, les fichiers système, la console entre autres. L’analyse effectuée s’est faite en incluant plusieurs paramètres permettant d’avoir des résultats qui reflètent le mieux la situation actuelle de la plateforme .NET.
Nombre de problèmes relevés par projet et par groupe
L’analyse des données des trois projets a montré que le nombre de problèmes relevés par les propriétaires du projet et les collaborateurs était supérieur au nombre de problèmes relevés par le reste dans la communauté pour le projet Roslyn avec seulement 40 % d’entre eux signalés par la communauté. Cependant, la communauté est beaucoup plus active sur le projet CoreCLR pour lequel le nombre de problèmes signalés par la communauté est supérieur au cumul de ceux signalés par les propriétaires et leurs collaborateurs. Cela peut s’expliquer notamment par le fait que CoreCLR soit la partie la plus visible de .NET, car englobant la plupart des bibliothèques utilisées par les développeurs .NET dans leurs programmes de tous les jours. Une autre raison de cette popularité de CoreCLR par rapport aux deux autres projets est qu’il est plus ancien. Les utilisateurs ont naturellement plus de suggestions d’améliorations ou de résolutions de bogues, ce qui n’est pas encore le cas de Roslyn qui est beaucoup plus récent sans compter le fait que les bogues du compilateur ne sont pas très faciles à détecter.
Nombre total de requêtes d’extraction par projet et par groupe
Sur ce plan, l’activité de la communauté est plus faible que celle des propriétaires et de leurs collaborateurs sur l’ensemble des trois projets avec seulement 12 %. Ce faible taux s’explique par le fait qu’il ne soit pas facile de faire une requête d’extraction qui aboutit. Pour faire une requête d’extraction qui aboutisse, il faut tout d’abord choisir une question relative à la partie concernant sa requête d’extraction, attendre de recevoir des modifications de l’API à travers un examen du code et répondre à toutes les exigences de comparabilité, de performance et d’exactitude. Cependant, il n’est pas aisé de donner des chiffres permettant de dire que la contribution de la communauté est plus importante ou non, même s’il faut noter que la participation de la communauté est assez consistante sur une période qui reste quand même relativement courte.
Les libellés des bogues signalés par projet
Le dernier paramètre considéré pour réaliser l’étude de la plateforme montre que le libellé « CodeGen » est assez fréquent du fait notamment que RyuJIT, le compilateur JIT de .NET avait été lancé il y a seulement quelques jours. Par ailleurs, le fait qu'il y ait un nombre de bogues aussi important en si peu de temps peut amener à se poser des questions, sachant que certains d’entre eux sont des bogues avec des conséquences graves comme le soulignent des statistiques publiées par Stack Overflow. Il est à noter aussi que les requêtes avec comme libellé « Up for Grubs » sont assez nombreuses pour tous les trois projets. Ce qui prouve que la communauté est en train d’approfondir ses connaissances sur les trois projets et montre un intérêt grandissant. Une dernière chose à noter et non des moindres est que les problématiques de la performance et de l’optimisation sont assez considérées par la communauté.
Source : mattwarren.org
Et vous ?
Quelle analyse faites-vous du framework .NET, un an après son passage à l'open source ?
Voir aussi
la rubrique .NET (Cours, Tutoriels, FAQ, etc.)
Passage de .NET à l'open source : un an plus tard
Comment se porte la plateforme de Microsoft ?
Passage de .NET à l'open source : un an plus tard
Comment se porte la plateforme de Microsoft ?
Le , par Victor Vincent
Une erreur dans cette actualité ? Signalez-nous-la !