Résistance open source : défendons l’open source pendant les heures de travail

 (ossresistance.com)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Open Source Resistance est un manifeste d’action directe appelant à assurer discrètement et professionnellement, pendant le temps de travail, la maintenance des logiciels open source dont dépendent les entreprises
  • Bien que toutes les entreprises ne puissent pas fonctionner sans open source, il refuse une structure qui pousse les mainteneurs à mendier une autorisation, un bouton de don ou quelques heures le vendredi après-midi
  • Il existait déjà des alternatives comme Open Source Pledge (demande de versement de 2 000 $US par an et par développeur) ou Open Source Friday (au moins 2 heures de contribution chaque vendredi), mais l’initiative assume une mise en pratique plus directe
  • À l’objection de « vol de temps », il répond que les entreprises bénéficient déjà depuis longtemps de subventions gratuites de l’OSS et que la maintenance des dépendances OSS relève d’un travail d’infrastructure partagée
  • Il faut impérativement vérifier les clauses de cession de propriété intellectuelle du contrat de travail et négocier par écrit une exception open source

Manifeste : ne demandez pas la permission pour réparer ce qui est déjà nécessaire

  • Open Source Resistance propose une action directe : ne plus reléguer au soir et au week-end la maintenance des logiciels open source (OSS) dont dépend l’entreprise, mais l’effectuer discrètement et professionnellement pendant les heures de travail
  • Le logiciel open source n’est pas un « hobby » de temps libre ; les entreprises extraient de la valeur de l’open source à chaque instant tout en n’offrant aux mainteneurs que quelques heures un vendredi après-midi, un bouton de don ou un mot de remerciement en réunion générale
  • Les mainteneurs au sein des entreprises devraient travailler sur le code OSS dont leur société dépend déjà sans paperasse, programme interne ni approbation managériale pendant leur temps de travail
  • Ce n’est pas une idée nouvelle, mais le fait de dire ouvertement comment la majorité de l’open source s’est toujours faite
  • Les mainteneurs ont fait tourner Internet sans attendre des réunions, des sprints ou l’autorisation d’un product manager

Principes d’action fondamentaux

  • Se protéger

    • Vérifier son contrat de travail, garder les informations confidentielles dans l’entreprise et s’assurer d’être propriétaire de l’IP open source que l’on publie

  • Faire le travail

    • Effectuer les revues de PR, les mises à jour de dépendances et les corrections de bugs sur les parties déjà open source

  • Ne pas être imprudent

    • Il ne s’agit pas de consacrer 100 % de son temps de travail à l’OSS puis de reprocher son licenciement aux autres : l’essentiel, c’est l’équilibre

Alternatives existantes

  • Open Source Pledge : demande aux entreprises de rémunérer les mainteneurs (2 000 $US par an et par développeur)
  • Open Source Friday : demande aux entreprises de donner du temps (au moins 2 heures chaque vendredi)
  • Il existe aussi une voie polie consistant à convaincre d’abord l’employeur, et toutes ces approches sont positives et méritent d’être soutenues
  • Open Source Resistance se présente comme l’étape suivante : affirmer que la maintenance de la chaîne de dépendances fait déjà partie du travail, même si le management ne la nomme pas ainsi
  • On ne contrôle pas la répartition du budget de l’entreprise, mais on peut contrôler la manière dont on utilise son temps de travail

Objections attendues et réponses

  • « C’est du vol de temps / du vol envers les actionnaires »

    • Les entreprises extraient déjà chaque jour de la valeur des mainteneurs open source, et les actionnaires bénéficient depuis des décennies de subventions open source gratuites
    • Si l’employeur dépend de l’OSS, le maintenir relève d’un travail d’infrastructure de bien commun, pas d’un vol

  • « Il faut demander l’autorisation »

    • Demander l’autorisation, c’est maintenir un déséquilibre de pouvoir
    • Il n’y a pas besoin de la bénédiction d’un manager pour maintenir une infrastructure dont l’employeur dépend déjà

  • « C’est comme le quiet quitting »

    • Le quiet quitting réduit la charge de travail, alors qu’ici il s’agit de produire l’infrastructure OSS sur laquelle Internet est construit
    • Le problème n’est pas le travail lui-même, mais le refus des entreprises de le reconnaître comme du travail

  • « Même les bons employeurs vont en pâtir »

    • Les bons employeurs évitent ce problème en autorisant la maintenance open source pendant le temps de travail, en finançant les mainteneurs ou en participant à l’Open Source Pledge

L’expérience de Mike McQuaid

  • Cofondateur d’Open Source Friday et de GitHub Sponsors, ainsi que responsable du projet Homebrew (mainteneur depuis 2009)
  • Dans aucun emploi, le travail sur un projet open source comme Homebrew n’a été rémunéré comme mission principale
  • Il l’a pourtant fait chez tous ses employeurs, en négociant ses contrats IP pour le rendre légal tout en respectant ses engagements professionnels
  • Depuis qu’il a des enfants, plus de 90 % de son travail open source est effectué pendant les heures de travail
  • Comme dans Open Source Maintainers Owe You Nothing, il estime que personne n’a le droit d’exiger des nuits, week-ends et temps familial non rémunérés d’un mainteneur simplement parce que le modèle économique d’une entreprise dépend de son code

Points d’attention et avertissement juridique

  • Ce n’est pas un conseil juridique

    • Le texte précise qu’il ne constitue pas un conseil juridique, ni un avis sur les contrats, l’employeur, le statut migratoire, les obligations de licence ou les situations individuelles
    • Si le risque est important, il faut consulter une personne qualifiée avant d’agir
    • Comme la plupart des licences open source, le texte est fourni « en l’état », sans aucune garantie

  • Contrats, politiques et propriété

    • Le contrat de travail, le règlement interne et les clauses de cession d’invention peuvent revendiquer des droits sur les travaux réalisés pendant l’emploi, sur le matériel de l’employeur ou dans le cadre des fonctions
    • Dans certains États, ces revendications sont limitées pour les travaux réalisés sur temps personnel et avec du matériel personnel, mais les détails comptent
    • Avant d’agir, il faut lire son contrat de travail et vérifier que l’employeur ne détient pas l’IP open source que l’on prévoit de publier
    • Si l’appareil, le réseau ou le compte modifient le risque de propriété, il faut utiliser les siens

  • Négocier le contrat IP

    • La cession d’IP est souvent négociable ; il est recommandé de demander par écrit une clause d’exception open source au moment de l’offre d’embauche, avant la signature
    • Il faut d’abord lire le guide sur les contrats IP des employés pour savoir à quoi s’opposer
    • Mike McQuaid indique avoir négocié avec presque tous ses employeurs des modifications aux contrats standards, avec bien moins de résistance que prévu dans la plupart des cas
    • Il est possible de montrer à un futur employeur le Balanced Employee IP Agreement de GitHub
    • Ce contrat a été open sourcé sous CC0, a été utilisé en pratique par une grande société cotée, et vise à ce que l’employeur conserve ce qu’il paie tandis que l’employé garde les travaux open source qui ne concurrencent pas l’activité de l’entreprise

  • Confidentialité et sécurité

    • Il ne faut pas divulguer de dépôts privés, d’identifiants, d’incidents, de données clients, de roadmaps, de vulnérabilités non publiées ni de discussions internes
    • Il ne faut pas contourner les contrôles de sécurité ni utiliser des accès non autorisés
    • L’action directe n’est pas un prétexte pour divulguer des informations confidentielles : il s’agit de garder public le travail public et de le séparer clairement des secrets commerciaux

  • Le silence ne signifie pas la négligence

    • Lorsque les politiques, contrats, obligations client ou règles de sécurité changent le niveau de risque, il faut faire preuve de jugement personnel
    • Il peut être nécessaire de travailler avec son propre matériel, ses propres comptes et son propre réseau
    • Il ne s’agit pas de « voler » son entreprise, mais de rééquilibrer ce que l’entreprise prend à l’open source et ce que l’on peut lui rendre
    • On peut recevoir une évaluation de performance inférieure à celle de ses collègues, mais un B durable reste plus sain que brûler sa vie pour un A dans une entreprise capable de licencier du jour au lendemain

  • Limites d’application

    • L’argument est le plus faible lorsque le temps est facturé à un client spécifique, à une subvention, à une agence publique, à un projet de défense ou à un environnement réglementé
    • Il est aussi le plus faible pour les ingénieurs juniors ou précaires qui n’ont pas le poids nécessaire pour absorber les conséquences
    • Il est le plus fort pour les mainteneurs seniors qui corrigent des dépendances publiques déjà utilisées par leur employeur
    • La forme la plus propre n’est pas « faites ce que vous voulez pendant vos heures de travail », mais traitez la maintenance open source comme une partie du travail d’ingénierie
    • Il faut maintenir les projets que l’on maintient déjà, améliorer les outils partagés que le travail touche, et éviter ce qui est sans rapport, le code propriétaire ou ce qui ferait manquer de vrais engagements

Source et projet

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Avis Hacker News

  • Il était en général assez courant que des entreprises donnent une autorisation générale pour contribuer à certains projets open source
    La manière de le présenter compte. Il ne faut pas dire : « Est-ce que je peux faire un peu de bénévolat pour me sentir bien ? », mais plutôt : « Est-ce que je peux obtenir gratuitement des revues rigoureuses de la part d’experts du domaine, faire intégrer nos correctifs dans le projet open source amont et ainsi éliminer les futurs coûts de maintenance pour l’entreprise ? »
    C’est en réalité le fond du sujet, et aucun employeur ne m’a jamais refusé quand je l’ai formulé ainsi. C’est totalement aligné avec l’intérêt de l’entreprise ; il suffit de l’aider à le voir

    • Il y a plusieurs choses que je regrette à propos de mon licenciement dans un ancien poste, et l’une des principales est qu’on était en train de discuter de la publication en open source d’un changement assez important que j’avais apporté à la bibliothèque Kafka Streams
      J’avais réécrit beaucoup de choses tout en gardant l’API largement compatible, avec une orientation vers des E/S non bloquantes permettant, si nécessaire, d’utiliser une sémantique de backpressure. Cela rendait possibles des usages intéressants, tout en conservant de bonnes performances même en mélangeant state stores et E/S bloquantes/non bloquantes, et j’étais particulièrement fier de ce projet parce qu’il améliorait les performances à plusieurs endroits peu visibles
      J’avais insisté pour qu’on me laisse le publier sur GitHub ou envoyer une PR au projet Kafka Streams amont, mais il y a eu des licenciements avant cela, puis il n’y avait plus de champion pour porter le sujet, donc c’est resté enfermé comme code propriétaire
      Je pense encore parfois à le recréer depuis zéro et à le publier comme open source libre. Assez de temps a passé pour que le réécrire et le publier ne pose sans doute pas de problème, il n’y avait pas non plus de brevet, et il y a des choses que j’aimerais changer, comme supprimer la dépendance à Vert.x. Peut-être qu’un jour, si j’ai une semaine de libre, je le ferai
    • Cette époque où je travaillais dans un endroit qui autorisait ce genre de choses me manque
      Dans certaines entreprises, rien que la procédure de validation juridique suffit à tout bloquer
      Une fois, j’ai demandé l’autorisation d’envoyer un patch à un projet, et une intéressante chaîne d’e-mails s’en est suivie. Au final, la question était simple : si le patch a été écrit sur du temps facturé au client pour corriger un bug d’un produit livré, que la bibliothèque patchée doit être recompilée et livrée avec le code source, et que le contrat dit que tout le travail et toute la propriété intellectuelle liés au produit sont transférés au client, avons-nous le droit de publier ce patch dans le domaine public ?
      L’équipe juridique n’avait pas envie de répondre
    • C’est globalement une bonne approche et un excellent exemple de cadrage professionnel du travail. Mais cela ne résout pas le fond du problème. En particulier, si la direction d’une entreprise orientée ingénierie ne comprend pas immédiatement ces avantages, c’est déjà un problème
      Et la manière dont on peut aborder la chose dépend aussi beaucoup de la chance qu’on a avec son employeur
    • « D’accord, je vais faire passer ça à l’équipe conformité. Juste pour vérifier qu’il n’y a pas de violation de propriété intellectuelle. C’est exactement quel dépôt et quel ticket ? »

  • À propos du conseil disant qu’il faut « bien posséder la propriété intellectuelle open source que l’on publie », dans les juridictions où j’ai travaillé, le code écrit et publié pendant les heures de travail appartenait à l’employeur, pas à moi
    Je ne pouvais pas décider seul de contribuer sur mes heures de travail, et il fallait un accord formel pour travailler sur du code open source. Chaque fois que je le demandais, cela prenait des mois via le service juridique, donc soit j’abandonnais, soit un autre contributeur avait déjà ouvert une PR entre-temps, et je ne demandais plus

    • Je pense qu’il voulait probablement dire qu’il ne faut pas « donner librement un travail qui ne vous appartient pas ». Il y a une section dédiée plus bas, mais la puce du haut seule prête à confusion
      Pour des développeurs expérimentés, cela va de soi, mais cela a réellement posé problème à certains développeurs juniors dans quelques entreprises. Quand une société fait quelque chose de sympa dans un projet interne, ils peuvent se dire que ce serait bien de le contribuer à un projet open source, sans se rendre compte qu’ils utilisent en pratique leur connaissance de code privé pour soumettre du code substantiellement similaire, voire parfois le copier-coller
    • Je ne l’ai pas vérifié moi-même, mais j’avais compris qu’en Allemagne, par défaut, tout le code source écrit pendant les heures de travail appartient à l’employeur
      La plupart des employeurs non centrés sur l’IT ne comprennent probablement même pas ce qu’est l’open source, ni comment cela fonctionne. Donc obtenir une autorisation de nombreuses personnes peut être désespérant
      Le site lié gagnerait à d’abord expliquer les avantages de l’open source aux employeurs, puis à défendre des lignes directrices juridiques à destination des employeurs
    • Si une entreprise refuse de publier sous licence permissive tout ce qui ne relève pas directement de la production, je n’irais probablement pas y travailler. Pour moi, c’est démotivant et ça me pousserait mentalement à bout. Je préférerais être plus pauvre

  • C’est une bonne idée, même une excellente idée, mais je ne sais pas si c’est pertinent de la présenter comme de la résistance
    Le but d’un poste est généralement d’atteindre un objectif. La façon d’y parvenir peut être laissée à l’expertise des développeurs. Si cette décision inclut du logiciel open source, alors sa maintenance devrait aussi faire partie de cette décision
    Ce n’est pas radical ; c’est simplement faire son travail en protégeant la stabilité future et la maintenabilité des choses dont ce travail dépend

    • C’est aussi simplement du bon sens business. Une entreprise qui encourage la collaboration via l’open source nourrit l’écosystème qui fait vivre son activité
    • Je suis d’accord avec tout ce qui a été dit, mais la réalité actuelle de la plupart des entreprises tech, dans mon expérience, est différente. Elles n’investissent déjà pas dans la maintenance de leur propre infrastructure et de leurs bibliothèques si ce n’est pas imposé, alors pour l’open source, c’est encore plus difficile
      Les fonctionnalités inutiles faites pour jouer avec les métriques, l’enshittification, les dark patterns et les intégrations à la mode proches du malware passent avant l’investissement dans l’infrastructure ou les bibliothèques de base
    • D’accord. Décrire les choses ainsi donne l’impression que quelqu’un cherche juste plus d’attention sur les réseaux sociaux. C’est triste d’en être arrivé au point où tout doit être exagéré

  • Je suis entièrement d’accord dans l’absolu, mais je pense que c’est difficile à faire en pratique. Je ne suis pas avocat, mais en général, l’employeur possède la propriété intellectuelle, donc une autorisation explicite est nécessaire pour publier en open source
    Et obtenir cette autorisation est souvent difficile, avec des procédures interminables et des passages obligés par le service juridique
    « Aux États-Unis, au Royaume-Uni et dans plusieurs autres juridictions, lorsqu’un salarié crée une œuvre dans le cadre de ses fonctions, l’employeur est considéré comme l’auteur légal ou le premier titulaire du droit d’auteur »
    https://en.wikipedia.org/wiki/Work_for_hire
    Cela dit, je pense quand même que le travail open source, c’est-à-dire la maintenance et le développement, devrait être fait par des professionnels rémunérés, pas par des bénévoles qui mendient des dons. La vraie question est de savoir comment y parvenir, et comment amener les entreprises à considérer la contribution à l’open source comme une pratique standard plutôt qu’une exception à négocier au cas par cas

    • Les problèmes décrits ressemblent moins à des « problèmes pratiques » qu’à des problèmes théoriques
      En pratique, il suffit de le faire. Il n’existe pas de sous-routine dans l’ordinateur qui bloque git push. En réalité, les employeurs écrivent toutes sortes de choses dans les contrats de travail. Ils en mettent autant que possible pour se protéger dans toutes les directions. S’ils peuvent écrire tout ce qu’ils veulent, pourquoi nous ne pourrions-nous pas simplement agir ? Rien n’a d’importance
      En pratique, il y a presque zéro projet open source réellement contesté sur la propriété intellectuelle pour ce genre de raisons techniques
    • C’est vrai que si le travail est lié à vos fonctions, l’employeur détient la propriété intellectuelle
      S’il n’est pas lié à vos fonctions, cela dépend des États. Beaucoup d’États limitent ce qu’un employeur peut revendiquer comme sa propriété intellectuelle. Les contrats standards essaient souvent d’élargir la formulation pour tout revendiquer, mais la loi dit fréquemment qu’une entreprise ne peut pas s’approprier du travail fait sur le temps libre sans rapport avec elle
      Si vous le faites pendant les heures de travail ou sur l’ordinateur de l’entreprise, cela lui donne des arguments pour revendiquer des droits. La plupart des entreprises ne s’en soucieront pas, mais s’il y a un conflit, il vaut mieux garder les choses propres
      Travaillez sur votre temps personnel, avec votre matériel personnel, et sans chevauchement avec ce pour quoi vous êtes employé ni avec ce à quoi vous avez eu accès dans l’entreprise
    • Je ne suis pas avocat, mais si vous avez donné une copie à un collègue pour qu’il l’exécute, n’est-ce pas déjà en soi un usage d’une licence open source ? Ce collègue obtient alors les droits juridiques accordés par la licence, y compris le droit de redistribuer les modifications, non ?
      Envoyer les changements en amont est la meilleure manière d’assurer la maintenance, donc tout cela me paraît assez absurde. Il en va de même pour l’incertitude juridique liée au maintien de forks propriétaires internes
    • L’article semble suggérer de suivre le chemin de moindre résistance. Faire le travail sur le temps de l’entreprise, sans faire de vagues. Si quelqu’un le remarque, il suffit de demander pardon. Du point de vue de l’entreprise, pardonner est l’option facile. Faire intervenir des avocats coûte très cher et peut devenir un cauchemar de communication
    • S’il y a bien une chose que l’état actuel de la programmation a montrée, c’est que la propriété intellectuelle et le droit d’auteur n’existent plus vraiment

  • Je travaille dans une assez grande entreprise. Notre politique open source se résume en gros à : « demandez d’abord à votre manager, ne le faites pas au nom de l’entreprise, et ne divulguez pas d’informations confidentielles »
    Ça n’a jamais posé problème, et dans l’ensemble cela me semble parfaitement raisonnable

  • Contribuer pendant les heures de travail à un projet open source tiers, par exemple avec une correction de bug, ne me semble pas poser problème, mais je ne sais pas comment traiter le cas de son propre open source
    Par exemple, imaginons une petite bibliothèque créée à titre personnel, ensuite utilisée au travail, et qu’on y découvre un bug pendant les heures de travail. Contribuer à ce moment-là me semble être une zone grise
    Est-ce que quelqu’un a déjà négocié ce genre de point pendant un entretien ? J’aimerais savoir comment cela s’est passé

    • Je n’ai jamais travaillé dans une entreprise qui se souciait réellement de ça. Je faisais simplement ce qu’il fallait. Même quand j’ai demandé comment faire les choses « correctement », je n’ai jamais obtenu de réponse

  • Quand je travaillais dans de grandes entreprises, en général, toute demande de travail autre qu’écrire directement du code dans la codebase de l’entreprise se voyait répondre par le manager direct : « faites-le sur votre temps libre », même si on en expliquait les raisons
    Dans un environnement orienté profit, seule la valeur immédiate est considérée comme digne d’intérêt. L’attitude est assez parasitaire, et la pression venue d’en haut pour plus d’efficacité et de compétition sur les métriques ne fait qu’aggraver cela

  • Il m’est clairement arrivé de forker quelque chose, de le corriger pour résoudre un problème au travail, puis d’envoyer le résultat en PR à l’amont
    C’est l’un des bons côtés de l’usage et de l’accessibilité de l’open source. C’est aussi pour cela que git est quasiment une option de premier ordre dans package.json et cargo.toml : on peut pointer directement vers son fork en attendant que les changements soient intégrés en amont

  • Quand on devient senior, au moment de l’entretien où l’on vous demande : « Avez-vous des questions pour nous ? », je demande : « Quelle est la position de l’entreprise sur le fait de consacrer une partie de mon temps aux projets open source dont elle dépend ? »
    Ensuite, il suffit de décider à partir de la réponse si l’on veut continuer ou rester