Qu’advient-il du code open source d’un projet après le décès de son développeur ?

Qu’advient-il du code open source d’un projet après le décès de son développeur ?
Quelles solutions préconisez-vous pour éviter les problèmes liés à l’abandon du code ?

Alors que l’on a assisté pendant longtemps à un combat entre les logiciels open source et les logiciels propriétaires, il faut reconnaître que depuis plusieurs années, ces deux mondes ne sont plus perçus comme opposés, mais plutôt complémentaires.

Un des avantages de ces logiciels open source, au-delà de la possibilité de contribuer facilement aux projets open source, est que le code open source peut être utilisé et modifié à souhait aussi bien dans les logiciels open source que commerciaux.

Jim Weirich est un développeur qui a eu son actif plusieurs outils open source comme Rake, Builder, RubyGems, Ruby KoanS et plus encore. Il fut également un contributeur très important de la communauté Ruby du monde occidental. En 2014, Weirich est décédé en laissant derrière lui une panoplie d’outils utilisés par un grand nombre de personnes. Mais pour assurer la pérennité de ces outils qui parfois étaient développés par Weirich uniquement, il faut reprendre ses projets.

Justin Searls, développeur chez Ruby et cofondateur de la société de logiciels Test Double, a noté qu’après le décès de Weirich en 2014, un des outils laissés par le développeur n’était pas maintenu. Cela signifie que s’il y avait des correctifs de sécurité et d’autres bogues qui étaient soumis par les contributeurs, il n’y aurait personne pour approuver ces changements. Au fil du temps, le code de l’outil deviendrait donc obsolète, car incompatible avec les nouvelles technologies.

À travers ce cas, Searls souligne que le décès de Weirich met en évidence une préoccupation croissante dans la communauté des logiciels open source. En d’autres termes, qu’advient-il du code open source après la disparition des développeurs ?

Bien que certaines personnes pourraient trouver une réponse simple en affirmant qu’il faut se tourner vers d’autres outils open source maintenus, le même problème se poserait à nouveau si l’outil est maintenu par une personne ou une petite communauté de bénévoles et que ces derniers sont indisponibles ou morts.

Pièce jointe 326839

Lorsque les entreprises développaient leurs logiciels sans avoir recours à des dépendances dans la communauté open source, le problème ne concernait qu’une poignée de personnes et donc était imperceptible. Mais avec l’intégration du code open source dans de nombreux logiciels commerciaux, l’importance d’assurer la maintenance du code open source à tout moment refait à nouveau surface.

Le cas de la faille Heartbleed détectée dans OpenSSL est un exemple édifiant. OpenSSL est une boîte à outils de chiffrement composée de deux bibliothèques (TLS et SSL). Il est utilisé par la majorité des entreprises sur la toile pour assurer la sécurité de leur communication pour leurs services commerciaux et non commerciaux. En 2014, une faille baptisée Heartbleed a été détectée dans ces outils et permettait à un pirate de récupérer le contenu de la mémoire du serveur sans laisser aucune trace numérique. Selon les informations rapportées, cet outil serait développé par une petite équipe de bénévoles qui n’avaient ni le temps ni les ressources nécessaires pour effectuer des audits de sécurité complets.

Au-delà des problèmes de sécurité occasionnés par l’abandon d’un projet open source, Searls rapporte que des problèmes de compatibilité peuvent voir le jour dans de nombreux logiciels lorsqu’un développeur meurt et abandonne un projet qui est intégré dans de nombreux logiciels.

Pour mieux montrer l’ampleur des problèmes générés par les projets open source non maintenus, Libraries.io, un groupe qui analyse les connexions entre les projets logiciels, a identifié plus de 2400 bibliothèques open source qui sont utilisées dans au moins 1000 autres programmes, mais ont reçu peu d’attention de la part de la communauté open source.

En guise d’exemple, l’an dernier, lorsque le développeur Azer Koçulu a supprimé une petite bibliothèque appelée Leftpad sur Internet, cela a créé un effet domino qui aurait provoqué des maux de tête à Facebook, Netflix et d’autres sites également.

Pour éviter l’abandon de l’outil de test Rspec-Given open source laissé par Weirich, Searls s’est tourné vers Github qui hébergeait le code du projet. Mais la plateforme a refusé de lui donner le contrôle de la page, car le propriétaire ne l’avait pas désigné comme nouveau gestionnaire du projet après sa mort.

À la faveur de ce problème, les yeux de Searls se sont ouverts sur les difficultés qui pourraient survenir après le décès des personnes qui assurent le développement des projets. Au sein du groupe de développement Ruby, Searls et les autres développeurs ont mis en place des processus qui permettent le transfert du contrôle d’un projet, lorsqu’ils constatent qu’un projet n’est plus maintenu. Et certains gestionnaires de paquets surveillent maintenant leurs bibliothèques et signalent les projets largement utilisés qui n’ont pas été mis à jour depuis longtemps. À cela, Searls suggère que GitHub et les gestionnaires de paquets tels que Gems pourraient ajouter à leur plateforme une fonctionnalité comme un « switch pour les hommes décédés », ce qui permettrait aux développeurs de transférer automatiquement la propriété d’un projet ou d’un compte à quelqu’un d’autre s’ils ne se connectaient pas à leur compte ou à leurs projets après une certaine période.

Au vu des difficultés qui pourraient survenir dans la gestion d’un projet open source après le décès de son propriétaire, quelles solutions pouvez-vous préconiser pour éviter ces problèmes ?

Source : Wired

Et vous ?

:fleche: Avez-vous déjà eu à faire face à un projet abandonné alors que vous l’utilisez toujours ?

:fleche: Quelles solutions peut-on préconiser pour régler les problèmes occasionnés par l’abandon du développement du code source d’un projet ?

Voir aussi

:fleche: Red Hat salue l'initiative de céder Java EE à une fondation open source et s'attend à une meilleure collaboration avec le projet Eclipse MicroProfile
:fleche: À partir de la fin de l'année 2020, Adobe mettra fin au support de son plug-in à succès Flash, comment envisagez-vous le web sans Flash ?
:fleche: Microsoft adhère à l'organisation Open Source Initiative en tant que sponsor premium pour soutenir davantage la communauté open source

Ce problème n'est aucunement lié à l'open source...
Si vous intégrez une librairie propriétaire à votre produit et que du jour au lendemain la société met la clé sous la porte vous vous retrouvez avec une librairie sans mise à jour.

Je comprend pas trop là, il suffit de forker. Si le type ne designe personne pour reprendre son projet, il meurt avec lui et continue sous un autre nom et c'est réglé.

Citation:

---

Avez-vous déjà eu à faire face à un projet abandonné alors que vous l’utilisez toujours ?

---

Ben ouais, je fork, je continue à mettre à jour en fonction de mes besoins et je colle les modifications en ligne. Si y'en a que ça intéresse tant mieux pour eux, sinon j'm'en bat les steaks :mrgreen:

Citation:

---

Quelles solutions peut-on préconiser pour régler les problèmes occasionnés par l’abandon du développement du code source d’un projet ?

---

Je ne vois vraiment pas où est le problème ? Si ce n'est que qu'il y a toujours eu plus de monde pour réclamer/exiger de la part d'un dev de logiciel mais dès qu'il faut se sortir les doigts...

Le but d'un logiciel libre est de pouvoir prendre les sources et d'adapter à ses besoins, le décès de son créateur n'est justement pas un soucis puisque son travail est publique.

Je pige vraiment pas le sens de cet article ou alors ce serait plutôt "mais qui va travailler gratuitement pour nous maintenant ?" le vrai problème. :aie:

Si le projet meurt définitivement c'est qu'il n'était pas aussi indispensable que ça.

Ca me fait penser à des types que j'ai croisé à mes début sur IRC, j'aidais des gens qui débutaient sous linux et quand je refusais de le faire en privé parce que ça pouvait aider plus de monde j'ai eu le droit à "Quoi ?!? mais pourquoi tu refuses de faire ce que je veux, tu devrais être content que je te demande de l'aide !". Cet article me fait vraiment penser à ce genre de personne :roll:

Citation:

---

Envoyé par transgohan

Ce problème n'est aucunement lié à l'open source...
Si vous intégrez une librairie propriétaire à votre produit et que du jour au lendemain la société met la clé sous la porte vous vous retrouvez avec une librairie sans mise à jour.

---

Je vous rejoinds sur ce point : avec du propriétaire de petites sociétés, on peut être coincé en cas de fermeture de la société ou arrêt du support, car pas de code source pour continuer.

Après, même en open source, on a déjà vu des créateurs tout supprimer du jour au lendemain, dont parfois pour basculer en licence propriétaire, et là c'est pas évident non plus...

Pour des outils essentiels autres que les OS, je préfère de l'open source, ce n'est pas parfait mais ça laisse une marge de manoeuvre quand même, on peut le voir par exemple avec LibreOffice (OpenOffice était mort, et aujourd'hui encore n'est pas très vivant).

Leur façon de s'approprier un projet délaissé ne tient pas la route.
Ca ressemble plus à du vol.
Un projet peut fonctionner avec peu de mises à jour.
Une fois qu'on arrive au terme du projet, il n'y a plus de mise à jour.

"Qu’advient-il du code open source d’un projet après le décès de son développeur ?"

Ou comment mettre en évidence un problème qui n'en est pas un!

1. Tout le monde finit par mourir... Même les développeurs

2. C'est justement parce qu'un logiciel est "Open Source" qu'il a une chance de survivre à son créateur! Le code est à la disposition de tous.

Donc, si le code open source en question doit être modifié, il peut être modifié par n'importe quel développeur de bonne volonté... On ne peut pas en dire autant des logiciels propriétaires: Il n'est pas rare qu'une société éditrice d'un logiciel disparaisse sans laisser la moindre possibilité de reprendre le code

Je coris que c'est plus un probleme juridique et cela dépend de la licence non ?

je vois plusieurs cas :

1)Dans le cas d'une licence permissive comme la WTFPL par exemple y'a aucun soucis, si le code est dispo sur le net n'importe qui peut piocher dedans sans rendre de compte à personne.
2) Si personne ne télécharge son projet et que le site ou il est hébergé le supprime il disparaît.
3) si cette personne m'a donné son code à moi et uniquement à moi, techniquement je peut en faire ce que je veut, respecter ces volontés et publier son code sur github, modifier la licence, m’approprier/voler son projet, vendre son projet en mon nom...
4) cas le plus complexe, dans certaine licence, si je viol une clause de la licence, qui vas me poursuivre puisque l'auteur est mort ?
Un exemple : dans certaines licence, si l'auteur meurt est on encore obligé par exemple de mentionner son nom si on l’utilise dans l'un de ces projets ? Si un individu lambda s’aperçoit que je viol les clauses de la licence peut t'il me poursuivre ? si oui à qui reviendra les sou-sou de l’amende ?

je m'interroge surtout sur les petits projets tenu par 1 seul développeur. Pour les gros projets comme Linux, si linus torvald meurt il y'aura évidement aucun changement au niveau de ces aspects. Puisque ce n'est pas des projets liées à une personnes mais des organisations (publique/privé) ou des "fundations".

Cela dit, un projet maintenu par 1 seul développeur, dans la majorité des cas c'est le projet qui meurt bien venant la mort de l'auteur. Il suffit de compter le nombre de projets laissé à l'abandon sur github/source code. Combien de projet n'ont pas reçu 1 commit depuis 5-6ans ?
6 ans étant une éternité en informatique, cela dépend du contexte, mais prenons du javascript par exemple si on a besoin de ce projet on a meilleur de temps d'e faire un nouveau que d'essayer de le reprendre et de le faire tourner sur les api d'aujourd'hui.

Ce genre de situation est exactement l'une des raison d'etre des Fondation Open-Source telles qu'Eclipse, Apache, Linux... Les Fondations offrent un modele de gouvernance et mettent en place des pratiques et processus qui premet facilement de delier le projet de ses contributeurs et de permettre au projet de continuer d'evoluer, sans fork, meme si les contributeurs quittent le projet. Certes, les Fondations viennent avec quelques contraintes sur le projet et cherchent generalement des $$ de la part des entreprises qui les utilisent, mais ce genre de cas montrent que ca peut vraiment valoir le coup pour des briques logicielles critiques.

Il y a une histoire de fric derrière :roll:
L'exemple parlait de facedeporc, netpic...
C'est cela le problème: l'argent !!!

Comme un projet n'est plus suivi qui va se plaidre si le code est repris par un autre, en changeant de license...?
Personne.
Une belle manière de s'approprié les bien des autres.

Citation:

---

Envoyé par Old Geek

Je comprend pas trop là, il suffit de forker. Si le type ne designe personne pour reprendre son projet, il meurt avec lui et continue sous un autre nom et c'est réglé.

---

Je pense que l'idée de la question est que ce n'est pas aussi simple que ça… Qui fork ? Vers quel fork se tourner ? Ta réponse est une réponse de technicien, mais la plupart des utilisateurs de "projets OpenSource" (au sens large : techno, bibliothèques…) ne le sont pas.

En théorie, les fondations répondent à cette inquiétude en montrant qu'un projet ne repose pas sur une personne. On verra au décès du premier BDFL…

Mais dans la pratique, la conséquence de cette question n'est pas différente de la question d'un abandon pur est simple ou d'un changement de cap…

Citation:

---

Envoyé par martopioche

En théorie, les fondations répondent à cette inquiétude en montrant qu'un projet ne repose pas sur une personne. On verra au décès du premier BDFL…

---

Oui et non, Les Fondations ne remplacent pas une Communaute, et ne garantissent pas non plus le projet d'en avoir une. Un projet dans une Fondation qui n'a qu'un seul contributeur continue de ne reposer que sur une personne, et une Fondation ne peut pas trop faire grand chose pour eviter ca. Elle peut aider les projets a former une communaute, mais c'est pas sur que ca marche, et de nombreux projets meme au sein de Fondation sont actuellement maintenus par leur auteur d'origine sans trop de contributions externes. Pour autant ces projets sont relativement perennes:
car la valeur des fondations, c'est plutot sur les processes: forcer l'utilisation d'outil ouverts a de nouveaux contributeurs et d'usage "public", forcer l'utisation de media de communication communautaire, transparence dans les decisions, recuperation des mots de passe necessaires aux services vitaux pour la survie du projet... et sur l'IP: verifier le choix d'une license qui laisse le projet vivre sa vie sans etre lie a des contributeurs en particulier, verifier que la Fondation/Communaute a les droits necessaires sur le code, les trademarks et compagnie... Ces processes permettent a un projet de faire face a des aleas comme le depart d'un contributeur, les embrouilles judiciaires, les embrouilles techniques et sont ce qui fait que le projet peut passer de main en main au fil du temps. La vie du projet peut continuer quoi qu'il en soit.
Un projet qui n'a pas ca va etre difficile voire impossible a reprendre en main s'il est abandonne. L'exemple recent que j'ai en tete c'est FindBugs, dont l'auteur a disparu comme pas magie, silence radio; et bah la communaute a du forker le truc pour faire SpotBugs: nouveau site, nouveau repo, nouveau artifacts... Beaucoup de boulot a du etre fait. Si ce projet avait ete dans une Fondation, alors n'importe quel contributeur se serait vu passer les pouvoirs normalement, et il n'y aurait pas eu a forker.

Je vous livre mon expérience car je me heurte au problème régulièrement avec le projet Unlicense-Lib

La license est le principale probleme, hormis lorsque le code est spécifié : WTFPL, Unlicense ou CC-0 alors il y a des conditions d'utilisations.
GPL est évidement la pire de toute ( la moins Open-Source), malheureusement souvent par ignorance les devs l'utilisent sans savoir ce qu'elle implique pour les autres.

Il faut alors contacter les auteurs et changer la license pour etre plus 'libre', pour le bien de tous j'ai envi de dire.
Et c'est la le probleme...

Il y a énormement de projet à l'abandon, surement les 3/4 de tous ce que l'on trouve sur bitbucket,github,google-code, ...etc...
Je considère un projet a l'abandon lorsqu'il n'y a pas eu de commits depuis au moins 4ans.

Il est difficile dans la plupart des cas de contacter les développeurs/contributeurs.
- Soit ils ne répondent pas
- Soit la boite mail est obsolete
- Soit c'est une fausse boite mail
- Soit il n'y a aucune information de contact

Donc dans les faits, un projet est souvent mort bien avant son propriétaire et pourtant il y a des petites pepites d'or un peu partout.
Plus le projet est vieux plus il devient difficile de recontacter les auteurs
Et a l'inverse plus le projet et recent, moins les auteurs sont enclins a placer leur code dans le domaine public.

Mon projet (Unlicense-Lib) est un cimitière de vieux projets (50+), un regroupement de code et de dons, et c'est aujourd'hui le plus grande base de code dans le domaine public.
Pour un projet intégrer c'est 9 qui n'ont pas abouti dont 5 car il a été impossible de contacter le/les auteurs.

Personnellement je pense qu'apres la mort d'un auteur,
s'il n'y a pas de disposition de prise a l'avance par celui-ci et que la famille ne s'y oppose pas,
alors le code devrait passer automatiquement dans le domaine public.

Faire des recherches afin de faire les développeurs (et uniquement eux :ave: ) des êtres immortels.

Citation:

---

Envoyé par Olivier Famien

Au vu des difficultés qui pourraient survenir dans la gestion d’un projet open source après le décès de son propriétaire, quelles solutions pouvez-vous préconiser pour éviter ces problèmes ?

---

Personnellement, je préconise d'éviter de mourrir.

Salut eclesia, peut-être que la licence Boost peut t'intéresser, dans le sens où tu peux la suggérer aux anciens contributeurs qui acceptent de te livrer leur code source pour Unlicence-Lib.
Boost a été créée initialement à destination des bibliothèques C++ mais couvre un périmètre agnostique (comprendre non limité à un langage).
Le compilateur DMD pour le langage D est d'ailleurs passé sous Boost en avril 2017.

Ce type de licence est partie intégrante de l'Open Source Initiative depuis mai 2008. Voici son lien officiel: http://www.boost.org/users/license.html

Ca ressemble à une license de type MIT, BSD, Apache2.
Merci mais malheureusement non, la license Boost ce n'est pas du domaine public.

Citation:

---

Envoyé par martopioche

Je pense que l'idée de la question est que ce n'est pas aussi simple que ça… Qui fork ? Vers quel fork se tourner ? Ta réponse est une réponse de technicien, mais la plupart des utilisateurs de "projets OpenSource" (au sens large : techno, bibliothèques…) ne le sont pas.

En théorie, les fondations répondent à cette inquiétude en montrant qu'un projet ne repose pas sur une personne. On verra au décès du premier BDFL…

Mais dans la pratique, la conséquence de cette question n'est pas différente de la question d'un abandon pur est simple ou d'un changement de cap…

---

On a un exemple assez parlant à ce sujet : TrueCrypt. Torpillé du jour au lendemain pour son ou ses auteurs pour d'obscures raisons, plusieurs repreneurs se sont manifestés. Plusieurs forks ont été créés dans la mêlée, mais au final le seul qui soit crédible et viable (et maintenu ?) est VeraCrypt. Projet qui corrige les failles et problèmes de sécurité de TC tout en ajoutant de nouvelles fonctionnalités et davantage de sécurité.

C'est une question de temps : au début c'est le chaos, personne ne sait vers quel saint se vouer, car tout le monde forke dans tous les sens. Puis les choses se tassent et les forks peu sérieux sont vite laissés de côté. C'est une démarche plutôt organique.

Je fais parti de ceux qui ne comprennent pas le titre, c'est plutot l'inverse: quid du code/evolution d'une application propriétaire après le décès de son developpeur, la faille de sa société éditrice ?

Avec l'opensource on a pas cette inquiétude, je vois par exemple une bibliothèque opensource très permissive, dont les auteurs ont décidé du jour au lendemain de refermé un peu la licence pour vendre leur solution aux professionnels

Certains utilisent la version devenu payante: Guriddo, d'autres ont profité de la nature opensource du projet initial pour forker la version précédent cette annonce

On a vu de même avec Mysql et OpenOffice/LibreOffice: le coté OpenSource à permis après un choix stratégique contestable de pouvoir forker une autre vision, continuité du projet :)

Par exemple pour Windows XP, on a le cas précis non pas d'un developpeur/société qui cesse son activité, mais c'est tout comme: l'éditeur stoppe les évolutions, mises à jour de son produit: celui-ci étant propriétaire: personne ne peut faire un fork pour continuer les evolutions de celui-ci...

Bonjour

Citation:

---

Je vous rejoinds sur ce point : avec du propriétaire de petites sociétés, on peut être coincé en cas de fermeture de la société ou arrêt du support, car pas de code source pour continuer.

---

C'est quoi ce problème avec les petites boites ? une grosse boite qui ferme ou arrête le support d'un truc posera le même problème qu'avec une petite ! Bien au contraire, une petite structure sera capable d'adapter ses conditions aux exigences d'un client (voir même de prévoir un plan de crise comme je le fais en ce moment avec un client), alors qu'une grosse boite vous imposera sa politique, qu'elle vous plaise ou pas.
Prenons Google en exemple par exemple ; leur services ou conditions changent sans arrêts, ils stoppent des projets (picasa et bien d'autres) ou en transforment d'autres du tout au tout (:langue:Google drive :rouleau: ou des API webs), ils sont petits ? vous pouvez exiger quelque chose de leur part ?
un autre exemple : Windows. W10 change toute l'ergonomie juste pour le fun et le marketing et massacre la productivité de millions d'utilisateurs, ils sont petits ? vous pouvez exiger quelque chose de leur part ?

Comme un projet propriétaire dépend que du contrat passé avec l"éditeur, un projet open source dépend de sa licence, non ?

Citation:

---

un projet open source dépend de sa licence, non ?

---

Il est soumis a sa license, mais ca ne veut pas dire que le projet va etre forcement maintenu; voire meme dans certains cas, ca ne veut pas dire que le projet va continuer a etre developpe en open-source... La seule difference avec du code proprietaire, c'est que comme le code a ete public a un moment, n'importe qui est en general cense pouvoir le reprendre et le forker dans les memes conditions en theorie. En pratique, certains projets OSS ont des APIs instables, meurent et compagnie comme il y en a aussi dans le monde proprietaire. Le fait que ce soit OSS ou non ne change pas grand chose a l'engagement de stabilite, qualite, longevite... du projet.
Si quelqu'un a une dependance critique sur un projet OSS qu'il veut voir continuer, la license ne constitue pas une garantie que des developpeurs vont continuer a travailler sur le projet. Mais il est possible d'etablir des contrats de support ou de prestation avec des contributeurs (individuels ou entreprise) pour s'assurer qu'ils vont travailler sur le projet. Un peu comme le contrat proprietaire va avoir tendance a amener l'argent des clients sur les produits achetes, les contrats de support ou de presta sur des projets OSS vont avoir tendance a amener l'argent des "investisseurs" sur les projets cibles.
Le contrat de support fournit aussi des garanties de service ou d'engagement qualite proche de celles d'un contrat pour un logiciel proprietaire.