Sans solution magique, la fondation recommande simplement de mieux prendre en compte le vieillissement technologique : plus une technologie est ancienne, moins elle est entretenue et plus son utilisation devient risquée.
C'est une évidence que les logiciels avec de petites communauté sont moins stable.
A l'inverse Awk, perl, emacs et d'autres même s'ils perdent de leur superbe garderont encore longtemps une communauté digne de ce nom capable de les maintenir.
Mais c'est pire dans le domaine propriétaire ou des que le vent tourne, il devient très difficile de continuer de travailler avec quand la boîte à coulé…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Ce rapport fourni plus des cas d'usage que de gros problèmes (à part pour Python, mais y avait-il besoin d'un rapport pour cela ??).
Certains passage de la traduction ne sont pas léger : 'Schéma normalisé de dénomination : le grand absent', ça fait très journalistique 'Grand absent', mouai… J'aurais préférer 'Convention de nommage non homogène ' : Chaque techno a des conventions nommages différentes, adressant souvent des choses qui n'ont rien à voir, donc bon (certaines n'en ont pas, et c'est un avantage dans certains cas)…
'Une poignée de contributeur' idem … Touds les projets ne sont pas de la taille d'un Linux, une dépendance Python qui bind du C++ n'a pas besoin de beaucoup de contributeurs! On fait dire n'importe quoi au chiffre, ce titre laisse entendre qu'il y a peu de contributeur, alors qu'en fait il montre que certains projets sont petit, c'est tout.
Ça reste intéressant, à condition de lire la version originale je pense. Ou pas.
Après avoir jeté un œil à la plaquette, j'ai l'impression que c'est surtout pour motiver les décideurs pressés à se pencher sur les projets de la LF. Les 4 derniers points de leur conclusion sont justement des plus values qu'ils apportent de base dans la gestion de projets qu'ils prennent sous leur coupole. On ajoute à ça un peu de banalités sur les technologies utilisées majoritairement (et qui recoupent justement les leurs.. statistiquement normales), et c'est tout.
Par contre, je ne me souviens pas du dernier projet que j'ai vu migrer de python 2 vers 3. A part des petits projets de bricolages postés sur un gist, il ne doit plus y en avoir beaucoup.
Ils se basent sur le fait que le package "six" est présent dans beaucoup de projets. J'aurais tendance à dire qu'une fois que six est présent, le projet devrait être supposé migré. Ils pointent aussi le sondage Jetbrains où 7% utilisent encore python 2, mais aucun lien avec l'open source. J'ai gardé un vieux routeur en linux 2.x, faudrait pas aussi l'inclure dans les stats ?
Bref, non, l'original semble à première vue tout aussi moyen bof.
# Vieillissement technologique
Posté par cg . Évalué à 5 (+3/-0).
Comme Bind, Apache, ou PHP :) ?
[^] # Re: Vieillissement technologique
Posté par Faya . Évalué à 6 (+4/-0).
Ou même Linux ! Je pense qu'il y a un contresens dans la traduction. L'étude parle de legacy code, pas de l'âge du logiciel.
[^] # Re: Vieillissement technologique
Posté par abriotde (site web personnel, Mastodon) . Évalué à 4 (+3/-0).
C'est une évidence que les logiciels avec de petites communauté sont moins stable.
A l'inverse Awk, perl, emacs et d'autres même s'ils perdent de leur superbe garderont encore longtemps une communauté digne de ce nom capable de les maintenir.
Mais c'est pire dans le domaine propriétaire ou des que le vent tourne, il devient très difficile de continuer de travailler avec quand la boîte à coulé…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Vieillissement technologique
Posté par Krunch (site web personnel) . Évalué à 4 (+2/-0).
D'ailleurs je me demande s'il existe un census équivalent pour les logiciels privateurs.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Pointe du doigt mouillée
Posté par YBoy360 (site web personnel) . Évalué à 7 (+5/-0).
Ce rapport fourni plus des cas d'usage que de gros problèmes (à part pour Python, mais y avait-il besoin d'un rapport pour cela ??).
Certains passage de la traduction ne sont pas léger : 'Schéma normalisé de dénomination : le grand absent', ça fait très journalistique 'Grand absent', mouai… J'aurais préférer 'Convention de nommage non homogène ' : Chaque techno a des conventions nommages différentes, adressant souvent des choses qui n'ont rien à voir, donc bon (certaines n'en ont pas, et c'est un avantage dans certains cas)…
'Une poignée de contributeur' idem … Touds les projets ne sont pas de la taille d'un Linux, une dépendance Python qui bind du C++ n'a pas besoin de beaucoup de contributeurs! On fait dire n'importe quoi au chiffre, ce titre laisse entendre qu'il y a peu de contributeur, alors qu'en fait il montre que certains projets sont petit, c'est tout.
Ça reste intéressant, à condition de lire la version originale je pense. Ou pas.
[^] # Re: Pointe du doigt mouillée
Posté par Elfir3 . Évalué à 4 (+2/-0).
Après avoir jeté un œil à la plaquette, j'ai l'impression que c'est surtout pour motiver les décideurs pressés à se pencher sur les projets de la LF. Les 4 derniers points de leur conclusion sont justement des plus values qu'ils apportent de base dans la gestion de projets qu'ils prennent sous leur coupole. On ajoute à ça un peu de banalités sur les technologies utilisées majoritairement (et qui recoupent justement les leurs.. statistiquement normales), et c'est tout.
Par contre, je ne me souviens pas du dernier projet que j'ai vu migrer de python 2 vers 3. A part des petits projets de bricolages postés sur un gist, il ne doit plus y en avoir beaucoup.
Ils se basent sur le fait que le package "six" est présent dans beaucoup de projets. J'aurais tendance à dire qu'une fois que six est présent, le projet devrait être supposé migré. Ils pointent aussi le sondage Jetbrains où 7% utilisent encore python 2, mais aucun lien avec l'open source. J'ai gardé un vieux routeur en linux 2.x, faudrait pas aussi l'inclure dans les stats ?
Bref, non, l'original semble à première vue tout aussi moyen bof.
# Annexes dans un format filtrable ?
Posté par Jona . Évalué à 3 (+1/-0).
Le rapport est à cette adresse : https://www.linuxfoundation.org/hubfs/LF%20Research/lfr_censusiii_120424a.pdf?hsLang=en
Ce serait intéressant d'avoir les annexes dans un format que l'on pourrait filtrer (p.ex.: csv). Quelqu'un a trouvé ça ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.