Qu'advient-il du code open source après le décès du développeur ?
Quelles solutions adopter pour éviter les problèmes liés à l'abandon du code ?

Le , par Olivier Famien, Chroniqueur Actualités
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.


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 ?

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

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

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
À 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 ?
Microsoft adhère à l'organisation Open Source Initiative en tant que sponsor premium pour soutenir davantage la communauté open source


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de transgohan transgohan - Expert éminent https://www.developpez.com
le 13/11/2017 à 11:06
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.
Avatar de - https://www.developpez.com
le 13/11/2017 à 11:17
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é.

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

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.

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
Avatar de Etre_Libre Etre_Libre - Membre éprouvé https://www.developpez.com
le 13/11/2017 à 11:25
Citation Envoyé par transgohan Voir le message
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).
Avatar de hotcryx hotcryx - Membre émérite https://www.developpez.com
le 13/11/2017 à 11:50
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.
Avatar de Anselme45 Anselme45 - Membre du Club https://www.developpez.com
le 13/11/2017 à 11:52
"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
Avatar de RyzenOC RyzenOC - Membre averti https://www.developpez.com
le 13/11/2017 à 12:31
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.
Avatar de Mickael_Istria Mickael_Istria - Membre chevronné https://www.developpez.com
le 13/11/2017 à 12:40
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.
Avatar de hotcryx hotcryx - Membre émérite https://www.developpez.com
le 13/11/2017 à 13:10
Il y a une histoire de fric derrière
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.
Avatar de martopioche martopioche - Membre éclairé https://www.developpez.com
le 13/11/2017 à 13:36
Citation Envoyé par Old Geek Voir le message
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…
Avatar de Mickael_Istria Mickael_Istria - Membre chevronné https://www.developpez.com
le 13/11/2017 à 14:13
Citation Envoyé par martopioche Voir le message
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.
Contacter le responsable de la rubrique Accueil