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
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 ?
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
Une erreur dans cette actualité ? Signalez-nous-la !