Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

104PARTAGES

6  3 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de 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.
20  0 
Avatar de Anselme45
Membre extrêmement actif 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
12  0 
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
10  1 
Avatar de SimonDecoline
Membre expert https://www.developpez.com
Le 13/11/2017 à 19:21
Citation Envoyé par Olivier Famien Voir le message

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.
5  0 
Avatar de imikado
Rédacteur https://www.developpez.com
Le 14/11/2017 à 22:14
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...
4  0 
Avatar de 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).
4  1 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 19/11/2018 à 9:48
Je viens de récupérer les sources des projets d'un membre de ma famille décédé. Ce sont des projets personnels, je n'ai pas eu le temps de regarde en détail ce qu'il y a dedans (je sais juste qu'il y a toutes ses sources depuis 20 ans : code, GPX, macros Ms Office), mais je me demandais quel droit j'ai dessus, sachant qu'il n'y a pas de licences associées.
Ces sources, cette propriete intellectuelle, appartient maintenant aux heritiers de cette personne. C'est a eux que tu dois demander le droit de les utiliser, publier, relicencier, vendre... maintenant; exactement comme tu aurais du le demander a l'auteur.
3  0 
Avatar de Mickael_Istria
Membre émérite 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.
2  0 
Avatar de Mickael_Istria
Membre émérite 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.
2  0 
Avatar de 23JFK
Membre expérimenté https://www.developpez.com
Le 13/11/2017 à 17:48
Faire des recherches afin de faire les développeurs (et uniquement eux ) des êtres immortels.
2  0