Je viens de contribuer (anonymement) à ce questionnaire et cela m'évoque un point qui appelle une petite remarque. On peut lire notamment, à plusieurs reprises :
Quels types de contact aviez-vous avec les autres participants du projet ?
- Mail
- Forum
- Chat
- Appels téléphoniques ou vidéo
- Contact direct
- Autre
Si historiquement c'est bien le mail qui a été le principal vecteur de l'effort de développement, il faut absolument prendre en compte aujourd'hui l'impact des logiciels de versioning et des hébergeurs de projets comme Github, qui à eux-deux permettent de prendre automatiquement en charge tout l'aspect « logistique » de la chose.
Je pense qu'aujourd'hui, il n'est pas exagéré de dire que ce type d'outil représente à lui seul autant d'activité que le reste des technologies présentées ici réunies.
Sur les projets publics, c'est à la fois le moyen le plus rapide d'obtenir et d'installer tout l'état de l'art concernant un projet en particulier, jusqu'à ses modifications les plus récentes, et c'est aussi la façon la plus certaine de retrouver le projet officiel puisque non seulement le développeur en charge du projet utilise les mêmes outils pour ses propres moyens, mais va aussi les partager par cette même voie.
Ça n'a l'air de rien mais lorsqu'un projet ne s'appuie pas dessus, la personne qui souhaite s'impliquer doit généralement retrouver le site web officiel du projet, s'assurer que c'est le bon, vérifier les dates de dernières mises à jour du contenu du site, récupérer la dernière « nightly build » ou package de développement officiel, puis récupérer les derniers patches en date sur la mailing list et les appliquer lui-même.
À l'usage, le dernier patch que j'ai envoyé et qui a donné lieu à une vraie modification l'a été sur le bugtracker du dépôt Github d'une des bibliothèques de ma distribution. Non seulement le bug tracker envoie automatiquement un mail aux personnes concernées (et/ou intéressées), mais on est également à peu près sûr que si le projet est actif, alors les développeurs le verront puisque leur espace de travail est au même endroit. En comparaison, j'avais déjà fait des bugs reports sur un bugzilla d'un projet GNOME et ils sont toujours restés lettres mortes.
Dans le même esprit, fin des années 1990, j'avais entrepris de désassembler et commenter les ROMs de mon vieux huit bit sur lequel j'avais fait mes premières armes. Cela avait beaucoup intéressé un autre développeur du même cercle, qui avait fini par faire la même chose dans son coin. Dans la première partie des années 2000, on en était encore à s'envoyer des disquettes par la poste, très occasionnellement, et qui ont fini par se perdre ou s'abîmer. Lui-même avait perdu une bonne partie de son travail à un moment, il m'avait même demandé si j'avais, moi, conservé son travail. Je n'en ai retrouvé que quelques bribes.
On a fini par laisser tomber la chose pendant près d'une dizaine d'années. Et plus récemment, un certain regain d'intérêt de la part de la communauté l'a remise au devant de la scène et comme le développeur en question s'était mis à Mercurial de son côté, j'ai fini par ouvrir un dépôt Atlassian pour les partager facilement (l'avantage supplémentaire étant que ce site permettait aussi de conserver le projet confidentiel, ce qui était nécessaire parce que les ROMs en question n'étaient pas libres à la base).
Ce qui est intéressant dans cette dernière anecdote, c'est que non seulement ce genre de structure est un formidable accélérateur pour les projets libres et/ou collaboratifs, mais que l'on constate que leur seule disponibilité est susceptible de revigorer des projets considérés comme morts depuis longtemps. On a coutume de dire que le libre s'est en majeure partie appuyé sur l'explosion du mail et de l'Internet grand public, ce qui est vraisemblable. Je pense que ces outils ont provoqué une deuxième révolution, probablement aussi importante.
Du coup, si c'est l'objet de ton étude, il serait intéressant de se pencher dessus en particulier, et de voir comment ils sont susceptibles de transformer le travail de bureau en général, spécialement à une heure ou le télé-travail est de plus en plus mis en avant.
# Git et compagnie
Posté par Obsidian . En réponse au message Questionnaire logiciel libre pour mémoire de master éco-socio. Évalué à 6.
Je viens de contribuer (anonymement) à ce questionnaire et cela m'évoque un point qui appelle une petite remarque. On peut lire notamment, à plusieurs reprises :
Si historiquement c'est bien le mail qui a été le principal vecteur de l'effort de développement, il faut absolument prendre en compte aujourd'hui l'impact des logiciels de versioning et des hébergeurs de projets comme Github, qui à eux-deux permettent de prendre automatiquement en charge tout l'aspect « logistique » de la chose.
Je pense qu'aujourd'hui, il n'est pas exagéré de dire que ce type d'outil représente à lui seul autant d'activité que le reste des technologies présentées ici réunies.
Sur les projets publics, c'est à la fois le moyen le plus rapide d'obtenir et d'installer tout l'état de l'art concernant un projet en particulier, jusqu'à ses modifications les plus récentes, et c'est aussi la façon la plus certaine de retrouver le projet officiel puisque non seulement le développeur en charge du projet utilise les mêmes outils pour ses propres moyens, mais va aussi les partager par cette même voie.
Ça n'a l'air de rien mais lorsqu'un projet ne s'appuie pas dessus, la personne qui souhaite s'impliquer doit généralement retrouver le site web officiel du projet, s'assurer que c'est le bon, vérifier les dates de dernières mises à jour du contenu du site, récupérer la dernière « nightly build » ou package de développement officiel, puis récupérer les derniers patches en date sur la mailing list et les appliquer lui-même.
À l'usage, le dernier patch que j'ai envoyé et qui a donné lieu à une vraie modification l'a été sur le bugtracker du dépôt Github d'une des bibliothèques de ma distribution. Non seulement le bug tracker envoie automatiquement un mail aux personnes concernées (et/ou intéressées), mais on est également à peu près sûr que si le projet est actif, alors les développeurs le verront puisque leur espace de travail est au même endroit. En comparaison, j'avais déjà fait des bugs reports sur un bugzilla d'un projet GNOME et ils sont toujours restés lettres mortes.
Dans le même esprit, fin des années 1990, j'avais entrepris de désassembler et commenter les ROMs de mon vieux huit bit sur lequel j'avais fait mes premières armes. Cela avait beaucoup intéressé un autre développeur du même cercle, qui avait fini par faire la même chose dans son coin. Dans la première partie des années 2000, on en était encore à s'envoyer des disquettes par la poste, très occasionnellement, et qui ont fini par se perdre ou s'abîmer. Lui-même avait perdu une bonne partie de son travail à un moment, il m'avait même demandé si j'avais, moi, conservé son travail. Je n'en ai retrouvé que quelques bribes.
On a fini par laisser tomber la chose pendant près d'une dizaine d'années. Et plus récemment, un certain regain d'intérêt de la part de la communauté l'a remise au devant de la scène et comme le développeur en question s'était mis à Mercurial de son côté, j'ai fini par ouvrir un dépôt Atlassian pour les partager facilement (l'avantage supplémentaire étant que ce site permettait aussi de conserver le projet confidentiel, ce qui était nécessaire parce que les ROMs en question n'étaient pas libres à la base).
Ce qui est intéressant dans cette dernière anecdote, c'est que non seulement ce genre de structure est un formidable accélérateur pour les projets libres et/ou collaboratifs, mais que l'on constate que leur seule disponibilité est susceptible de revigorer des projets considérés comme morts depuis longtemps. On a coutume de dire que le libre s'est en majeure partie appuyé sur l'explosion du mail et de l'Internet grand public, ce qui est vraisemblable. Je pense que ces outils ont provoqué une deuxième révolution, probablement aussi importante.
Du coup, si c'est l'objet de ton étude, il serait intéressant de se pencher dessus en particulier, et de voir comment ils sont susceptibles de transformer le travail de bureau en général, spécialement à une heure ou le télé-travail est de plus en plus mis en avant.