• La propriété privée au secours des forêts ? (ou les paradoxes des nouveaux communs sylvestres) – – S.I.Lex – via @mona
    https://scinfolex.com/2019/08/19/la-propriete-privee-au-secours-des-forets-ou-les-paradoxes-des-nouveaux-c

    A la fin du mois dernier, le philosophe Baptiste Morizot – auteur des ouvrages Les Diplomates et Sur la piste animale – a publié une intéressante tribune sur le site du journal Le Monde, intitulée « Si la propriété privée permet d’exploiter, pourquoi ne permettrait-elle pas de protéger ? ». On la retrouve en libre accès sur le site de l’association ASPAS (ASsociation pour la Protection des Animaux Sauvages), sous le titre « Raviver les flammes du vivant ». Ce texte avait pour but de soutenir le projet « Vercors Vie Sauvage » porté par l’ASPAS qui cherchait à rassembler 650 000 euros en financement participatif afin d’acquérir 500 hectares de forêt – formant auparavant un domaine privé de chasse – pour établir une « Réserve de vie sauvage », en libre évolution.

  • Local-first software

    You own your data, in spite of the cloud

    https://www.inkandswitch.com/local-first.html

    C’est très long, mais bien fait. Idéalement, les applications et documents devraient :
    – être rapides
    – être accessibles simultanément sur plusieurs dispositifs
    – fonctionner sans connexion
    – être modifiables par plusieurs personnes en même temps
    – être encore accessibles à long terme
    – n’être accessibles qu’aux personnes autorisées (et pas la NSA)
    – rester sous contrôle de l’utilisateur.trice

  • The Linux desktop is in trouble | ZDNet
    https://www.zdnet.com/article/the-linux-desktop-is-in-trouble

    Jason Hicks, Muffin maintainer and member of the Linux Mint team, observed on Reddit, as reported by Brian Fagioli:

    I also have a life outside open-source work, too. It’s not mentally sound to put the hours I’ve put into the compositor. I was only able to do what I could because I was unemployed in January. Now I’m working a job full time, and trying to keep up with bug fixes. I’ve been spending every night and weekend, basically every spare moment of my free time trying to fix things.

    There’s also been tension because we’re 1-2 months from a release. We’ve had contentious debate about input latency, effects of certain patches, and ways to measure all of this. Other team members are going through their own equally hard circumstances, and it’s an unfortunate amount of stress to occur all at once at the wrong times. We’re human at the end of the day. I wish these aspects didn’t leak into the blog post so much, so just wanted to vent and provide some context. If you take away anything from it, please try the PPA and report bugs. We need people looking for things that might get stuck in cinnamon 4.2.

    I’ve heard this before. There have been a lot of Linux desktop distros over the years. They tend to last for five or six years and then real life gets in the way of what’s almost always a volunteer effort. The programmers walk away, and the distro then all too often declines to be replaced by another.

    It is not easy building and supporting a Linux desktop. It comes with a lot of wear and tear on its developers with far too little reward. Mint is really a winner and I hope to see it around for many more years to come. But I worry over it.

    Looking ahead, I’d love to see a foundation bring together the Linux desktop community and have them hammer out out a common desktop for everyone. Yes, I know, I know. Many hardcore Linux users love have a variety of choices. The world is not made up of desktop Linux users. For the million or so of us, there are hundreds of millions who want an easy-to-use desktop that’s not Windows, doesn’t require buying a Mac, and comes with broad software and hardware support. Are you listening Linux Foundation?

    #Logiciels_libres #Linux #GUI #Economie

    • 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.

  • The World’s Email Encryption Software Relies on One Guy, Who is Going Broke
    http://www.propublica.org/article/the-worlds-email-encryption-software-relies-on-one-guy-who-is-going-brok

    The man who built the free email encryption software used by whistleblower Edward Snowden, as well as hundreds of thousands of journalists, dissidents and security-minded people around the world, is running out of money to keep his project alive.

    Werner Koch wrote the software, known as Gnu Privacy Guard, in 1997, and since then has been almost single-handedly keeping it alive with patches and updates from his home in Erkrath, Germany. Now 53, he is running out of money and patience with being underfunded.

    #chiffrement

  • « Suite au déménagement du #Figoblog, certaines personnes ont été émues par ma décision de ne pas assurer la continuité de service sur les URL des billets. En effet, comment peut-on consacrer tant d’énergie à défendre la cause des identifiants pérennes et se retrouver au final, tel le cordonnier, si mal chaussé ? Quelques explications s’imposent. »

    http://figoblog.org/2015/01/06/pourquoi-sacrifier-url

    #URL #Web #pérennité

  • Issues for Research Software Preservation | Library & Collections
    http://libraryblogs.is.ed.ac.uk/blog/2013/09/18/research-software-preservation

    les chercheurs devraient-ils sauvegarder des images complètes de leurs serveurs de calcul ?

    In their paper ‘A Framework for Software Preservation’ (doi:10.2218/ijdc.v5i1.145) Matthews et al describe four aspects of software preservation:1. Storage: is the software stored somewhere?2. Retrieval: can the software be retrieved from wherever it is stored?3. Reconstruction: can the software be reconstructed (executed)?4. Replay: when executed, does the software produce the same results as it did originally?

    #recherche #perennité

  • IEEE-USA Position Statement Against Use of Universal Identifiers (UIDs)
    http://www.ieeeusa.org/policy/positions/universalidentifiers.html

    (Approved by the IEEE-USA
    Board of Directors, 15 Feb. 2001)

    The Institute of Electrical and Electronics Engineers - United States of America (IEEE-USA) strongly recommends that use of a “universal identifier (UID)” — an identifier implemented in all interactions of an individual or other entity with its society — be explicitly rejected.

    comme le fait délicatement remarquer @karlpro ce lien est mort, pour lire cette position adoptée le 15 février 2001 , il faut aller rechercher sur archive.org
    http://web.archive.org/web/20041106011802/http://www.ieeeusa.org/policy/positions/universalidentifiers.html
    ou dans les archives d’une newsletter
    http://www.ieee.org/organizations/pubs/newsletters/npss/0601/against_UID.htm
    #surveillance #identification_personnelle #fichage #pérennité

  • Nobody Puts Data in a Corner | the engine room
    https://www.theengineroom.org/nobody-puts-data-in-a-corner

    One person or organization should not have the power to erase information we use from the internet or to bar access to it, especially when it has been conceived, funded, and produced as a public good. As a community of human rights defenders, we need to design a better solution for how to protect and preserve our information.

    #web #pérennité #accès #précarité #ong

  • Ce week-end c’était Backup day | Carnet de notes
    http://n.survol.fr/n/ce-week-end-cetait-backup-day

    vu que l’essentiel de mes données sensibles sont des photos, j’ai pris pour habitude de faire des tirages réguliers et conséquent (je chasse les promos) car à mon avis, en plus de la sauvegarde physique, rien n’assure que les RAW seront consultables dans 10, 15, 20 ans, et de manières aisée. La bonne vielle boite à chaussure de photos sera le support qui perdurera pendant longtemps je pense.

    Commentaire de Julien sur un billet d’Eric D.

    Je pense assez comme lui.

    #sauvegarde #pérennité #numérique #digital-archive

  • Archiveteam
    Vous avez dit pérennité des contenus ?
    http://archiveteam.org/index.php?title=Main_Page

    D’après cet article l’Archiveteam est le sauveteur du patrimoine culturel du monde.
    http://www.heise.de/tr/artikel/Die-Retter-des-Web-Kulturerbes-1628473.html

    Warum sich aber die Mühe machen, größtenteils unbekannte Gedichte und andere Inhalte zu sichern, die nur bestimmten Individuen oder allenfalls Grüppchen wichtig sind? Sind solche Daten es überhaupt wert, gerettet zu werden? Für Zweifler hat der Gründer von Archive Team, der im Internet nur als „Jason Scott“ auftritt, keinerlei Verständnis. Die große New York Public Library bewahre schließlich auch alte Restaurantkarten in ihrer Sammlung seltener Bücher auf. „Das stellt niemand infrage“, grantelt der Datenretter. Wenn Webseiten-Betreiber Nutzern erst anböten, ihre Seiten zu hosten und dann plötzlich dichtmachten, dann sei das, „als ob jemand in das Bibliotheken-Geschäft einsteigt und dann beschließt, es ist doch nichts für ihn und den Laden niederbrennt“. Dabei trage jede Seite das einmalige Handzeichen der Person, die sie entwickelt hat.

    Es sind genau diese persönlichen Details, die das Archive Team zu retten versucht, Zeugnisse des alltäglichen Lebens, die für jemanden wichtig genug waren, um im Internet veröffentlicht zu werden. Von der „Petsburgh“ getauften Unterseite von GeoCities – einst der Drittplatzierte in der Rangliste der meistbesuchten Webdienste – sicherte das Archive Team zum Beispiel eine digitale Erinnerungstafel, die einer für seinen Hund Woodro angelegt hatte. Auf der Tafel stand zu lesen, dass Woodro zu Lebzeiten ein Fan der Musik von Jimmy Buffett gewesen war und am 5. Januar 1998 „seinen Kampf gegen Lungenkrebs verloren“ hatte. Für das Archive Team allemal ein Grund zum Eingreifen. Trotzdem gingen insgesamt 38 Millionen solcher selbst gestalteten Seiten verloren, als GeoCities von seinem Betreiber Yahoo 2009 wegen zu hoher Betriebskosten abgestellt wurde.

    #pérennité_des_contenus #dev_null