• Le premier :
      https://framablog.org/2016/09/12/des-routes-et-des-ponts-1

      Pourtant, je suis tombée sur un certain nombre de projets open source qui mettaient à mal ces préjugés. Il s’est avéré que maintenir les projets dans la durée était un problème connu dans le monde des contributeurs de l’open source. Plus je creusais la question et plus je découvrais des billets de blog, des articles et des forums de discussion qui abordaient la tension et l’épuisement éprouvés par ceux qui maintiennent les projets open source. Tout le monde m’indiquait une autre personne à contacter et sans m’en apercevoir j’ai récolté un nombre incroyable de témoignages à ce sujet.

      Je me suis rendu compte que j’avais découvert un problème certes « bien connu » des producteurs (les contributeurs de l’open source) mais dont les consommateurs (les entreprises de logiciels et les autres utilisateurs de code open source) n’avaient apparemment aucune idée. Cette anomalie m’a incitée à me pencher sur le problème.

      Par ailleurs, il semble que le milieu de l’open source soit lui-même en train d’évoluer, voire de bifurquer. J’ai eu des conversations très diverses avec des interlocuteurs de différentes générations, tous contributeurs open source. Ils semblaient avoir des philosophies et des valeurs divergentes, au point de donner l’impression de ne pas utiliser le même vocabulaire. J’ai appris que dans les trois à cinq dernières années, la production ainsi que la demande avaient explosé dans le monde de l’open source grâce à l’amélioration des outils pour les développeurs et à celle de l’organisation du travail. Les contributeurs de l’open source d’aujourd’hui sont très différents de ceux d’il y a 10 ans, sans parler de ceux d’il y a 30 ans. Or ces différentes générations ne communiquent pas entre elles, ce qui rend difficile toute conversation productive sur la maintenance pérenne des logiciels.

      #épuisement #travail #pérennité #long_terme #infrastructure

      Aussi signalé par @monolecte
      https://seenthis.net/messages/523810
      et
      https://seenthis.net/messages/525857

    • https://framablog.org/2016/11/14/des-routes-et-des-ponts-9-largent-et-lopen-source

      Beaucoup de projets open source ne sont rien de plus qu’un dépôt numérique public où est stocké du code auquel un groupe de gens contribue régulièrement : l’équivalent d’une association officieuse sur un campus universitaire. Il n’y a pas de structure légale et il n’y a pas de propriétaire ou de chef clairement défini. Les « mainteneurs » ou les contributeurs principaux émergent souvent de facto, en fonction de qui a créé le projet, ou de qui y a investi beaucoup de temps ou d’efforts. Cependant, même dans ces cas-là, dans certains projets on répugne à introduire une hiérarchie favorisant clairement un contributeur par rapport à un autre.

      […]

      La nature décentralisée du monde open source en a fait ce qu’il est : des logiciels produits de façon participative, que n’importe qui peut élaborer, partager, et améliorer. Mais quand vient le moment de discuter des besoins organisationnels, ou de la viabilité, il peut être difficile de prendre des décisions faisant autorité.

      […]

      De plus, de nombreux projets fonctionnent très bien de manière communautaire lorsqu’ils sont d’une des deux tailles extrêmes possibles, c’est-à-dire soit des petits projets qui ne demandent pas de maintenance significative (comme dans l’exemple de Arash Payan et Appirater), soit de très gros projets qui reçoivent un soutien important de la part d’entreprises (comme Linux).

      Cependant, beaucoup de projets sont coincés quelque part entre les deux : assez grands pour avoir besoin d’une maintenance significative, mais pas d’une taille suffisante pour que des entreprises déclarent leur offrir un soutien. Ces projets sont ceux dont l’histoire passe inaperçue, ceux dont on ne parle pas. Des deux côtés, on dit aux développeurs de ces projets « moyens » qu’ils sont le problème : du côté des « petits projets », on pense qu’ils devraient simplement mieux s’organiser et du côté des « gros projets », on pense que si leur projet était « assez bon », il aurait déjà reçu l’attention des soutiens institutionnels.

      […]

      Beaucoup de projets open source sont en train d’expérimenter la difficile transition d’une création désintéressée à une infrastructure publique essentielle.
      Ces dépendances toujours plus nombreuses signifient que nous avons pour responsabilité partagée de garantir à ces projets le soutien dont ils ont besoin.

      #organisation

    • https://framablog.org/2016/12/05/des-routes-et-des-ponts-13-des-mecenes-pour-les-projets-open-source

      La deuxième option pour financer des projets d’infrastructure numérique consiste à trouver des mécènes ou des donateurs. Il s’agit d’une pratique courante dans les cas de figure suivants :
      – Il n’existe pas de demande client facturable pour les services proposés par le projet.
      – Rendre l’accès payant empêcherait l’adoption (on ne pourrait pas, par exemple, faire payer l’utilisation d’un langage de programmation comme Python, car personne ne l’utiliserait ; ce serait comme si parler anglais étant payant).
      – Le projet n’a pas les moyens de financer des emplois rémunérés, ou bien il n’y a pas de volonté de la part du développeur de s’occuper des questions commerciales.
      – La neutralité et le refus de la commercialisation sont considérés comme des principes importants en termes de gouvernance.

      […]

      Pour expliquer sa décision de lever des fonds pour un projet open source, Godwin écrit :

      « Une quantité importante de code open source est écrit gratuitement. Cependant, mon temps libre est limité. Je dispose actuellement d’une seule journée libre par semaine pour travailler, et j’adorerais la consacrer à l’amélioration de Django, plutôt qu’à du conseil ou à de la sous-traitance.

      L’objectif est double : d’une part, garantir au projet un temps de travail conséquent et au moins 80 heures environ de temps de codage ; et d’autre part prouver au monde que les logiciels open source peuvent réellement rémunérer le temps de travail des développeurs. »

      […]

      John Resig est l’auteur de jQuery, une bibliothèque de programmation JavaScript qui est utilisée par près des 2/3 du million de sites web les plus visités au monde. John Resig a développé et publié jQuery en 2006, sous la forme d’un projet personnel. Il a rejoint Mozilla en 2007 en tant que développeur évangéliste, se spécialisant notamment dans les bibliothèques JavaScript.

      La popularité de jQuery allant croissante, il est devenu clair qu’en plus des aspects liés au développement technique, il allait falloir formaliser certains aspects liés à la gouvernance du projet. Mozilla a alors proposé à John de travailler à plein temps sur jQuery entre 2009 et 2011, ce qu’il a fait.

      À propos de cette expérience, John Resig a écrit :

      « Pendant l’année et demi qui vient de s’écouler, Mozilla m’a permis de travailler à plein temps sur jQuery. Cela a abouti à la publication de 9 versions de jQuery… et à une amélioration drastique de l’organisation du projet (nous appartenons désormais à l’organisation à but non lucratif Software Freedom Conservancy, nous avons des réunions d’équipe régulières, des votes publics, fournissons des états des lieux publics et encourageons activement la participation au projet). Heureusement, le projet jQuery se poursuit sans encombre à l’heure actuelle, ce qui me permet de réduire mon implication à un niveau plus raisonnable et de participer à d’autres travaux de développement. »

    • https://framablog.org/2016/12/12/des-routes-et-des-ponts-14-synthese-sur-les-difficultes-de-financement

      En plus de l’enjeu macroéconomique des communs, il y a plusieurs raisons pour lesquelles le financement des infrastructures numériques est particulièrement compliqué. Ces raisons ont déjà été abordées au cours de cette étude, mais sont toutes résumées ici.

      On croit à tort qu’il s’agit d’un « problème résolu ».
      […]

      Il manque une prise de conscience et une compréhension culturelle de ce problème.
      En dehors de la communauté open source, tout le monde, ou presque, ignore les problèmes de financement de ces projets d’infrastructure, et le sujet est perçu comme plutôt aride et technique. Les développeurs qui ont besoin de soutien ont tendance à se concentrer principalement sur la technique et sont mal à l’aise lorsqu’il s’agit de défendre l’aspect financier de leur travail. Au bout du compte, on ne parvient pas à trouver l’élan qui pourrait modifier cette situation en panne.

      Les infrastructures numériques sont enracinées dans l’open source, dont la culture du bénévolat n’encourage pas à parler d’argent.
      Même si cette attitude a fait de l’open source ce qu’elle est aujourd’hui, elle crée également un tabou qui rend difficile pour les développeurs l’évocation de leurs besoins, car ils se sentent coupables ou ont peur de passer pour des personnes qui n’auraient pas l’esprit d’équipe.

    • Le livre est intéressant, et elle aborde frontalement l’épuisement des gens et des projets, ainsi que la nécessité d’ouvrir au maximum les projets à plein de profils différents pour maximiser les contributions, l’écosystème, le cercle vertueux, dans le dernier chapitre.

      Mais une reproche que je ferais, c’est qu’elle ne parle que de financement direct. Et donc uniquement de projets, qui même lorsqu’ils sont très communautaires et à but non lucratif, sont seulement ceux qui ont une fondation ou association officielle qui permet de récolter des dons privés ou publics, pour ensuite le redistribuer à des développeureuses, des gens qui font la doc, la com ou autre.

      Bon, on est vraiment mais alors VRAIMENT parmi les seuls au monde entier dans SPIP à être une communauté sans aucune structure juridique officielle. Du coup c’est très difficile de s’identifier dans son livre et de faire des rapprochements.

      Par ailleurs, elle aborde un peu le financement indirect mais pas tant que ça et ce n’est pas très détaillé sur le type de tâches que ça permet de faire avancer.

      Cela fait des années que je redis régulièrement la même chose, mais je pars de mon expérience dans SPIP évidemment. J’affirme, et je pense que c’est quantifiable et que je peux le prouver, que mis à part au début, la majorité des dernières contributions à SPIP dans les dernières années plugins ET noyau, l’ont été soit durant des temps travaillés et payés, soit en rapport avec le travail quand même car investissement du fait que SPIP est la base sur laquelle est montée le travail, le salaire, la vie des gens qui ont fait ces contributions. Je ne parle donc pas que de moi. Je trouve qu’il y a une sorte de non-dit sur ce sujet, volontaire ou pas, et que c’est un fait difficile à reconnaitre (et donc à en tirer les conséquences !).

      De manière plus concrète : un (très) grand nombre de plugins majeurs ont été créé et/ou augmenté dans le cadre de fonctionnalités nécessaires durant des projets payés par des clients à des gens qui vivent de SPIP. Pour le noyau, de nombreuses modifications ont été fait dans ce même cadre, et certaines majeures au moment du montage de Nursit, pour la sortie de SPIP 3.0. Pour moi il s’agit clairement d’un investissement, qui sert à monter une activité plus stable ensuite. Je ne fais strictement aucune critique : je trouve ça très bien et sain. Mais je voudrais juste qu’on le reconnaisse plus explicitement : non malgré nos (y compris moi !) positionnements très libertaires, en défense du monde associatif et militant, etc, et bien non, la plupart des plus grosses évolutions en plugins importants et en noyau, n’ont pas été fait bénévolement pour l’amour de l’art ou pour servir le militantisme gauchiste.

      Malheureusement ce type de financement indirect, qui est donc assimilable pour moi à du « mécénat », par la redistribution de nouvelles fonctionnalités ou d’amélioration de l’existant à toute la communauté, permet de faire avancer seulement des fonctionnalités précises (« on veut pouvoir créer des sélections de contenus manuellement », « on veut pouvoir payer en ligne », etc) ou des corrections de bugs ou des améliorations pas trop énormes.

      Je n’ai jamais vu qu’un mécénat comme ça, fournissant du temps, arrive à « financer » des modifications majeures d’infrastructure, de communication, d’ergonomie générale.

      En effet, durant un projet pour un client, on peut arriver à faire financer la création d’un nouveau plugin, ou l’amélioration d’un truc existant. Mais personne ne va jamais financer la refonte complète de l’admin qui est un chantier énorme de plusieurs mois à plein temps. Et personne ne va financer la refonte complète et mise en cohérence des documentations, qui est aussi un énorme chantier. De même nous avions parlé avec @marcimat de la refonte de l’infrastructure au cœur du logiciel, en utilisant des librairies existantes (composer, sfy…) : c’est aussi un énorme chantier de plusieurs mois (et qui à mon avis est essentiel à long terme, autant que l’admin ergonomique et responsive).

      Pour tous ces énormes chantiers, quand bien même on arriverait à s’organiser de manière moins bloquante et conflictuelle qu’avant (comme je l’ai déjà exposé), ça ne change rien au fait que le temps à y passer est énorme, et qu’il ne peut être uniquement bénévole (même s’il y en a aussi, on passe tous plus de temps, pas payé, à améliorer SPIP), sinon on n’a plus de vie, et c’est burn out, etc. On a tous une vie, une famille, des enfants, des ami⋅e⋅s, des loisirs, des lectures… En dehors de nos heures de travail, on ne peut pas faire que continuer à coder pareil.

      Prendre pour étalon de la contribution l’idéal-type d’une personne qui en plus de ses 7h par jour à coder pour le travail, re-passe 4h par jour (ou plus !) à contribuer bénévolement, ce n’est pas possible, on ne peut pas plus anti-inclusivité que ça à mon sens. (Et l’autrice du livre va entièrement dans ce sens.)

      Voilà un peu une partie de mes sentiments autour d’une manière de s’organiser dans « ma » communauté qui n’a justement pas de fondation à qui donner des dons, et dont on est assez fier, mais qui a de gros soucis à se faire dans les années qui arrivent d’après moi.