L’avenir de l’open source

 (blog.gitbutler.com)
19 points par xguru 2024-08-12 | 5 commentaires | Partager sur WhatsApp
  • Anne, notre COO et cofondatrice, a été poursuivie en justice lorsqu’elle était CEO de l’entreprise alimentaire allemande Delinero. Un fournisseur avait étiqueté une confiture de framboise comme "Himbeermarmelade", alors qu’en Allemagne il existait une Konfitürenverordnung (réglementation sur les confitures) selon laquelle un produit ne peut être étiqueté "marmelade" que s’il contient au moins 20 % d’agrumes
  • C’était une règle contraire au sens communément admis du mot, mais comme il s’agissait d’une loi créée il y a longtemps par un petit nombre de parties prenantes, il fallait s’y conformer
  • On peut considérer que l’"open source" actuel est dans une situation similaire. L’OSI continue de réglementer strictement un terme qui a évolué différemment de son usage courant, à la manière de la Konfitürenverordnung
  • Mais comment avancer dans une direction constructive ?

Comment ne pas faire de l’"open source"

  • Quand GitButler a publié le code client en "Fair Sourcing" sous une licence non approuvée par l’OSI, nous nous sommes demandé comment l’annoncer
  • La plupart des gens assimilent l’"open source" à "ce qui est public sur GitHub", et, en raison des implications parfois risquées des licences GPL/copyleft, les gens ont aussi l’habitude de vérifier très attentivement quelle licence s’applique
  • Nous ne voulions pas utiliser un terme vague comme "Source Available'd", et pour éviter toute confusion nous avons utilisé le mot "open", mais nous avons été attaqués
  • Nous avons compris qu’une petite minorité très bruyante cherchait à protéger ce terme et à lui donner un sens strict
  • "Open source" n’est pas la négation logique de "closed source". Il existe un écart entre la compréhension populaire — quelque chose de public sur GitHub et ouvert à la participation — et les 10 critères techniques de l’"open source" auto-régulés par l’OSI

Brève histoire de l’open source

  • À l’époque des débuts de l’informatique, dans les années 1950-1960, le logiciel était lié au matériel, il n’était donc pas nécessaire de le distinguer séparément, et les fabricants de matériel le distribuaient librement
  • Dans les années 1970-1980, avec la banalisation du matériel, le logiciel a acquis une valeur propre, et de grandes entreprises comme IBM et AT&T ont commencé à restreindre l’accès au code source qu’elles développaient à grands frais
  • En réaction, Richard Stallman et d’autres ont commencé à créer leur propre OS et leurs propres outils, protégés des intérêts des entreprises, et avec des licences réciproques comme la GPL, ils forçaient IBM, AT&T et les autres à rendre leurs propres logiciels libres s’ils utilisaient les leurs

    "Si nous ne pouvons pas jouer avec vos jouets, alors vous ne pouvez pas jouer avec les nôtres."

    • Ils ont appelé ce mouvement le "logiciel libre" et ont créé de nombreux outils remarquables comme Emacs et le système de compilation GNU. Ce sont encore aujourd’hui des outils fondamentaux de l’informatique moderne
    • L’objectif fondamental du mouvement du logiciel libre était de garantir aux utilisateurs la liberté d’exécuter, copier, distribuer, étudier, modifier et améliorer les logiciels — des libertés qui leur avaient été retirées par les intérêts des entreprises de l’époque
  • Au début des années 1990, le noyau Linux de Linus Torvalds a permis de disposer d’un OS complet, et l’écosystème du logiciel libre, avec la pile LAMP et d’autres composants, s’est développé au point que les entreprises ont commencé à l’utiliser et à en dépendre
  • En 1997, Eric Raymond a publié l’essai "La Cathédrale et le Bazar", affirmant que le modèle de développement du logiciel libre était supérieur au modèle fermé, et ce texte a été cité pour justifier l’ouverture du code source de Navigator Suite par Netscape
    • Lorsque Netscape a décidé de publier son code source, Raymond et plusieurs développeurs Linux et du logiciel libre de premier plan ont convenu, lors d’une session stratégique à Palo Alto, de créer et d’utiliser le nouveau terme "open source"

    "Les participants à la réunion estimaient que les arguments pratiques et commerciaux qui avaient poussé Netscape à ouvrir son code constituaient un moyen valable de communiquer avec les utilisateurs et développeurs potentiels, et de les convaincre de rejoindre la communauté pour créer et améliorer le code source. Les participants pensaient aussi qu’il serait utile de disposer d’un label unique permettant d’identifier cette approche et de la distinguer du label “logiciel libre”, plus philosophique et politique."

  • Le point important est qu’il n’existe pas de différence juridique ou pratique substantielle entre le "logiciel libre" et l’"open source"
    • La plupart des licences sont compatibles avec les deux définitions et reconnues par les deux
    • "Open source" n’est qu’un changement de marque plus favorable au business, destiné à dissocier les objectifs politiques de Stallman et de son mouvement de la praticité de l’ouverture logicielle, afin d’encourager davantage d’entreprises comme Netscape à adopter l’ouverture de leur code source professionnel
  • Ou, comme le disent les partisans du logiciel libre

    "L’open source est une méthodologie de développement, le logiciel libre est un mouvement social."

L’open source à l’ère de GitHub

  • La définition et le marketing de l’expression "open source" remontent à 1998, il y a maintenant plus de 25 ans. Alors, que s’est-il passé dans l’open source et le développement logiciel durant ces 25 dernières années ?
  • En particulier, ces 10 dernières années, GitHub et le style de développement logiciel à la GitHub ont eu un impact immense sur l’open source
  • En 1998, il fallait convaincre les entreprises d’adopter le logiciel ouvert ; aujourd’hui, presque tous les logiciels open source sont écrits ou sponsorisés par des entreprises
  • L’un des plus grands changements a été la "standardisation des workflows de développement", en particulier sous l’impulsion de GitHub
  • Autrefois, il existait une grande différence entre les projets de logiciels ouverts et les projets d’entreprise ; aujourd’hui, il n’y en a presque plus
    • Tout le monde utilise Git
    • Presque tout le monde utilise les pull requests (ou merge requests, ou une autre variante de cette fonctionnalité)
    • La plupart des équipes utilisent une forme de GitHub Flow (développement basé sur le trunk, GitLab Flow, etc.)
  • Désormais, la seule différence est qu’un dépôt soit public ou non. Il y a 25 ans, il existait beaucoup de friction dans le processus ; aujourd’hui, ouvrir un projet ne demande presque aucun changement de processus

Quelle est la prochaine étape pour l’open source ?

  • Maintenant que presque toutes les entreprises utilisent et produisent des logiciels open source, peut-on dire que le mouvement open source (logiciel libre) a réussi ?
  • Le monde de l’open source fait aujourd’hui face à deux grands problèmes : la "durabilité des développeurs" et la question de savoir si l’open source commercial est viable

Le problème de la durabilité des développeurs

  • À mesure que la dépendance à l’open source a augmenté, des problèmes de durabilité et de maintenance sont apparus. L’exploitation de la porte dérobée dans XZ Utils en est un exemple récent bien connu
  • Presque tous les mainteneurs souffrent aujourd’hui d’épuisement et de harcèlement. Gagner sa vie en écrivant et en maintenant des logiciels open source est presque impossible
  • La plupart des développeurs et mainteneurs open source sont désormais sponsorisés par de grandes entreprises
    • Si l’on regarde Linux, Git, Ruby, React, etc., la majorité des contributeurs des projets open source importants sont employés à titre professionnel par des sponsors comme GitHub, Microsoft ou Red Hat
  • Il est difficile pour un développeur de tirer un revenu correct en maintenant un projet comme XZ Utils
    • Au lieu qu’une seule entreprise paie un développeur, l’idéal serait que des milliers d’entreprises versent de petites sommes à des mainteneurs professionnels
  • Le principal problème est qu’il n’existe pas encore de bon moyen de faire cela
    • Il existe des initiatives prometteuses comme GitHub Sponsors, Thanks.dev, Liberapay ou Tidelift, mais elles n’ont pas encore résolu la question des bonnes incitations pour que les entreprises donnent
  • Sentry pousse une nouvelle initiative appelée OSS Pledge, et GitButler prévoit d’y participer lors de son lancement en octobre
  • Mais on ne sait pas encore si ce type d’approche pourra résoudre le grand problème, croissant, de la durabilité des développeurs dans l’écosystème open source

Le problème de l’open source commercial

  • Les développeurs ont grandi en aimant l’open source et les communautés ouvertes ; lorsqu’ils lancent une entreprise ou un projet, ils veulent donc par défaut l’ouvrir
    • Mais, tout comme pour les mainteneurs individuels, l’open source a aussi un problème de durabilité côté entreprise
  • Comme l’ont montré les cas d’Elasticsearch et de Redis, lorsqu’on investit du temps et de l’argent pour développer un logiciel de manière professionnelle, on court le risque que de grandes entreprises comme Amazon utilisent ce travail pour entrer directement en concurrence
  • De nombreux créateurs professionnels veulent investir dans leur logiciel sans qu’il soit ensuite utilisé contre eux
    • Cela signifie faire preuve de créativité dans les licences ou refermer le code source
  • Je pense que le mouvement Fair Source est une excellente réponse, nécessaire, à ce problème croissant, et qu’il comble le vide de l’écosystème open source qui a créé de plus en plus de problèmes et de confusion ces dernières années
    • C’est, selon moi, une solution indispensable : un nouveau terme pour désigner des projets professionnels largement permissifs, avec code source disponible et participation de la communauté GitHub, afin d’encourager davantage de projets qui seraient autrement restés privés à être rendus publics

L’avenir de la collaboration

  • L’avenir de l’open source ne se résume pas à "Open Source" et aux 10 règles de la Konfitürenverordnung de l’OSI
  • Il repose sur une combinaison d’Open Source accessible et utile à tous, de Fair Source nécessaire à des investissements sûrs, et d’un financement collaboratif à grande échelle pour les bibliothèques et projets open source fondamentaux
  • Nous devons rendre durable la maintenance des bibliothèques open source importantes, et accepter puis normaliser une catégorie de licences commerciales durables avec code source disponible
  • Il faut rendre open source, sous des licences OSI aussi permissives que possible, tout ce qui peut l’être, et surtout reléguer le closed source au passé
  • Ce que vous pouvez faire dès maintenant
    • transformer les logiciels fermés en Fair Source
    • et, si vous dépendez de l’open source, rejoindre OSS Pledge

À lire aussi

5 commentaires

 
bus710 2024-08-13

La réalité, dans un monde capitaliste, c’est qu’on ne peut pas se consacrer uniquement à l’open source. D’un autre côté, je me dis que, pour des bibliothèques ou utilitaires vraiment importants, il serait bon que les entreprises accordent davantage de sponsoring.

Les utilitaires de bureau/terminal en espace utilisateur ont particulièrement du mal à bénéficier de ce type de soutien. Pour le noyau, les grandes entreprises apportent beaucoup de soutien ; pour le mobile, l’App Store est bien commercialisé ; et pour le web ou le firmware, on développe généralement après une certaine analyse de marché, donc c’est un peu moins préoccupant. En revanche, pour les logiciels et bibliothèques que les utilisateurs ordinaires utilisent sans même s’en rendre compte, il est assez difficile ne serait-ce que de définir un seuil d’entrée, donc j’ai l’impression qu’il est vraiment très difficile d’en tirer des revenus. L’open source est assez dynamique, mais il n’est pas facile de passer au niveau supérieur.
 
bus710 2024-08-13

Autant j’aime l’open source et l’utilise avec plaisir, autant j’aimerais que celles et ceux qui, dans l’ombre, se dévouent à développer avec acharnement pour le plus grand nombre puissent eux aussi bénéficier d’un choix de licence approprié.
 
chabulhwi 2024-08-13

Dans le texte de Drew Devault intitulé « So you want to compete with or replace open source (Vous voulez donc concurrencer ou remplacer l’open source ?) », on trouve le passage suivant.

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

Les logiciels libres et open source génèrent un bénéfice mutuel lorsque des contributeurs appartenant à différentes organisations collaborent entre eux, mais dans le cas du fair source software, il y a peu, voire aucune, raison pour que d’autres contributeurs collaborent gratuitement au profit d’un individu ou d’une organisation bénéficiant d’une position monopolistique.

Quoi qu’il en soit, moi aussi je pense que le fair source est préférable au closed source, et je ne souhaite pas non plus voir des mainteneurs de logiciels open source vouloir être rémunérés pour leurs efforts sans pouvoir l’être.

Je doute simplement que le fair source puisse, comme l’open source, bénéficier gratuitement des contributions au développement. Et lorsque quelqu’un choisit de distribuer son logiciel en open source, il doit garder à l’esprit qu’il ne recevra peut-être aucune compensation financière de ses utilisateurs, et que ce logiciel peut devenir un « free lunch » pour les géants du cloud.