Alimenter l'avenir de l'Open Source
Saisissez votre part de notre fonds de durabilité Open Source de 20 millions de dollars
Financement des mainteneurs.
Soutenus par l'expérience.
Nous avons écrit des correctifs pour des bases de code non maintenues, traqué des vulnérabilités là où personne d'autre ne regardait, et maintenu le fonctionnement de systèmes critiques en toute sécurité sans réécritures précipitées. Ce fonds s'appuie sur ce travail, afin que les responsables de la maintenance puissent continuer à faire ce qu'ils font le mieux, en bénéficiant d'un véritable soutien.
Nos critères et notre engagement
Les critères de notre programme se concentrent sur l'hygiène et la sécurité de l'écosystème afin de guider et de soutenir les meilleures pratiques en matière de logiciels libres. Nous nous associons à des équipes pour les aider à respecter ces normes et leur fournissons des fonds pour renforcer et pérenniser leur impact sur la communauté open-source.
Versions et versionnage
Utiliser des versions prévisibles et documentées (SemVer/PEP 440), annoncer les nouvelles versions par tous les canaux officiels et indiquer clairement les corrections liées aux CVE.
Communication et transparence
Indiquez clairement quelles sont les versions prises en charge, obsolètes ou en fin de vie, et informez les utilisateurs à l'avance des modifications, avec des délais adaptés à la taille du projet.
Documentation
Définir des politiques de dépréciation, étiqueter les versions dépréciées, spécifier les délais de prise en charge et indiquer quand les versions seront entièrement supprimées.
Gestion de l'assistance et de la déchéance
Fournir des calendriers clairs d'adoption/suppression, rétroporter les correctifs critiques vers la LTS uniquement, maintenir les dépréciations sans rupture, et faire apparaître les avertissements dans les changelogs et dans le temps d'exécution.
Processus et niveaux
Maintenir des processus clairs pour signaler les problèmes et les préoccupations en matière de sécurité, définir des niveaux de support (actuel, LTS, EOL) et encourager la migration ou d'autres solutions de support lorsque les versions atteignent la fin de leur vie utile (EOL).
Sélectionnez cette option pour obtenir une vue par critères :
Version Fin de vie
- La communauté est informée d'une libération lorsqu'elle a lieu.
- Doit être communiqué via tous les canaux officiels (X/Twitter, GitHub Repo, documents du site web, etc).
- Définition claire de ce qui se passe lorsqu'une nouvelle version est publiée.
- Définit l'impact d'une version majeure, mineure ou d'un correctif.
- Lorsqu'une nouvelle version est publiée, la communauté connaît l'état d'avancement de l'assistance pour les versions précédentes.
- Les publications qui traitent des CVE sont identifiées comme suit
- Informer la communauté de l'existence ou non de correctifs permettant d'atténuer les vulnérabilités connues.
- Il est recommandé qu'un projet utilise une version standard de l'industrie (par exemple Semantic Versioning ou, pour les paquets PyPi, PEP 440).
- Si le projet ne suit pas actuellement SemVer, la structure de versionnement est prévisible, intuitive et documentée pour la communauté.
- La documentation indique clairement quelles sont les versions en fin de vie et celles qui sont prises en charge.
- Annonce des sorties
- De nombreux petits projets ont tendance à sortir une nouvelle version majeure avec peu ou pas d'avertissement, abandonnant immédiatement le support pour les anciennes versions majeures ; les projets plus importants ont tendance à prévoir les nouvelles lignes de publication à l'avance et à indiquer explicitement une période de support à long terme pour la ligne de publication précédente.
- Les annonces d'événements EOL sont faites en temps utile.
- Délais de référence à prendre en compte :
- Bibliothèques/cadres de base largement adoptés : 12-18 mois
- Projets modérément adoptés (plus de 10 000 utilisateurs) : 6-12 mois
- Projets de petite taille et/ou de niche : 3-6 mois
- Le cas échéant, une période de support est prévue pour les versions antérieures afin de permettre une transition ou une migration.
- Délais de référence à prendre en compte :
- Les événements de fin de vie sont publiés sur les canaux officiels du projet.
Dépréciation
- Il existe une définition de la dépréciation
- Comment est-elle traitée ?
- S'il reçoit des corrections de bogues ou des correctifs
- Comment les vulnérabilités affectent ces versions
- Le balisage est utilisé dans tous les documents officiels pour signaler les versions obsolètes.
- Lorsqu'une nouvelle version a un impact sur le statut d'une version antérieure, il existe une documentation indiquant quelle(s) version(s) devient(nt) obsolète(s) et/ou en fin de vie.
- Un délai est spécifiquement mentionné quant à la date à laquelle une version obsolète sera complètement supprimée et/ou ne sera plus du tout prise en charge.
- Le cas échéant, le projet s'appuiera sur des outils spécifiques à l'écosystème pour signaler les dépréciations.
- Un calendrier est recommandé à la communauté :
- l'adoption de nouvelles fonctionnalités, et
- Suppression des fonctionnalités obsolètes.
- Il existe une structure pour la prise en charge des fonctionnalités obsolètes. Exemple :
- Introduit dans les versions mineures
- Supprimé dans la prochaine version majeure
- Les vulnérabilités critiques ne sont reportées que dans la version LTS.
- Les dépréciations doivent être irréversibles.
- Les avertissements d'exécution sont ajoutés dans les journaux / la console pendant l'utilisation.
- Les événements de dépréciation apparaissent dans les journaux de modification et les notes de mise à jour.
Politiques de soutien
- Il existe une procédure permettant à la communauté de signaler des problèmes.
- Une procédure est en place pour répondre aux problèmes signalés.
- Une procédure est en place pour signaler les violations de la sécurité.
- Définir les niveaux de support des versions de manière à ce qu'ils soient clairs pour la communauté.
- Exemple 1 :
- Actuel : Prise en charge complète des vulnérabilités de sécurité et des bogues.
- LTS : vulnérabilités de sécurité uniquement.
- Fin de vie : si critique, vulnérabilités en matière de sécurité.
- Exemple 2
- Dernier en date (ou pris en charge)
- Non pris en charge
- Exemple 1 :
- La documentation destinée aux développeurs indique clairement quelles sont les versions prises en charge et celles qui ne le sont pas.
- Des attentes sont définies quant aux versions dont l'utilisation est recommandée aux développeurs (supportées) et à celles qui sont destinées à la préversion ou au développement.
- Lorsqu'une version devient obsolète, les utilisateurs sont encouragés à migrer OU à mettre en place une solution d'assistance si la migration n'est pas envisageable pour l'instant.
- Note : Cela peut se faire par le biais des services de HeroDevs afin d'établir des calendriers de migration ou d'identifier les versions plus anciennes qui restent prises en charge.
Construire des logiciels plus sûrs grâce à de meilleures pratiques de fin de vie
Questions fréquemment posées
Bien entendu, si vous ne trouvez pas la réponse que vous cherchez, n'hésitez pas à nous contacter.