Développement et gestion de Logiciel Libre et Ouvert (LLO)

8 018 vues

Publié le

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
8 018
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6 809
Actions
Partages
0
Téléchargements
30
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Développement et gestion de Logiciel Libre et Ouvert (LLO)

  1. 1. Atelier Développement et gestion de Logiciel Libre et Ouvert (LLO) 25 juillet 2013 Daniel Morissette dmorissette@mapgears.com
  2. 2. Daniel Morissette ● Président, Mapgears Inc ● Bac Génie informatique, UQAC, 1994 ● Dév. de logiciel libre et ouvert et membre de comités de direction: ● GDAL/OGR (1998+) ● MapServer (2000+) ● Démarrage et contribution à plusieurs autres projets LLO ● Fondation OSGeo ● Charter member (2006+) ● Board of directors (2010+) et trésorier (2011+) ● Chapitre local OSGeo-Québec (2008+) ● Prix Sol Katz en 2009 ● Incubateur OSGeo: ● 3x mentor (MapGuide Open Source, FDO, MetaCRS) ● “chair” du comité incubation en 2011
  3. 3. Fondations LLO
  4. 4. Développement / gestion de LLO ● Introduction ● Acteurs / Communauté LLO ● Infrastructure technique ● Processus de gestion ● Exemples d'application des processus ● Autres considérations ● Incubateur ● Liens utiles
  5. 5. Introduction
  6. 6. “Libre” ou “Open Source”? ● L'“Open Source” est une méthodologie de développement (motivations pratiques) ● Le “Libre” est un mouvement social (motivations éthiques) ● Les motivations diffèrent mais les deux groupes se rejoignent sur la solution
  7. 7. Qu'est-ce qu'un logiciel?
  8. 8. Logiciel * Image courtoisie de “Master isolated images” / FreeDigitalPhotos.net
  9. 9. Logiciel libre et ouvert Licence Programme Code Source Documentation d'utilisation
  10. 10. Logiciel propriétaire Licence Programme EXE Documentation d'utilisation
  11. 11. 11 Les licences
  12. 12. Définition d'une licence libre ● Une licence libre ou ouverte doit garantir les 4 libertés suivantes: ● d'utiliser ● de copier ● d'étudier ● de modifier et redistribuer
  13. 13. Catégories de licences
  14. 14. 14 Licences – Obligations ??? L'utilisation de code Open Source dans votre application vous oblige à a) retourner vos modifications/améliorations au projet OS correspondant b) publier l'ensemble de votre code source sous la même licence c) aucune obligation de publication dialog-question.png: Human-O² Icon Set (c) Olivier Scholtz and others
  15. 15. 15 Licences GPL LGPL MIT/X BSD Réciproque (copyleft) Non-réciproque
  16. 16. 16 Licences ● Le choix de la licence est très important. C'est une décision stratégique (vs réciprocité ou non) qui doit être faite en début de projet Avec une licence libre/ouverte, on ne cède pas sa propriété intellectuelle, on l'utilise pour rendre le code libre
  17. 17. 17 Modèle de fonctionnement Éditeur propriétaire vs Projet LLO
  18. 18. Modèle de l'éditeur propriétaire * Image courtoisie supercoloring.com $ $ $$ $ $ $ $ $ Direction R&D Marketing RH ... Prod. Mgr, devs, docs, QA, etc $ $ $$ $ $ $ $ $
  19. 19. Modèle du projet LLO (Mythe) Image: Paul Ramsey, Beyond Nerds Bearing Gifts, The future of the Open Source Economy
  20. 20. Modèle du projet LLO Communauté (à la fois conepteur, gestionnaire et utilisateur)
  21. 21. Modèle du projet LLO Communauté (à la fois conepteur, gestionnaire et utilisateur)
  22. 22. Modèle du projet LLO Communauté (à la fois conepteur, gestionnaire et utilisateur)
  23. 23. Modèle du projet LLO Communauté (à la fois conepteur, gestionnaire et utilisateur)
  24. 24. Modèle du projet LLO ● Les membres de la communauté agissent à titre individuel, même s'ils sont payés par un employeur ● Les entreprises et organismes sont bienvenus mais n'ont pas de statut spécial au sein de la communauté, ils sont représentés par des individus ● La communauté d'un LLO mature a des règle de fonctionnement claires que nous allons découvrir
  25. 25. Acteurs / Communauté LLO
  26. 26. Acteurs / Communauté LLO ● Usagers (de débutants à “power users”) ● Contributeurs actifs: ● Développeurs, architectes ● Rédacteurs de docs, traducteurs, graphistes, etc ● Autres contributeurs, testeurs (réguliers ou intermittents) ● Statuts spéciaux: ● Membres du comité de direction ● “Committeur” ● Les individus peuvent jouer plusieurs rôles (ex: un usager, peut être aussi contributeur et membre du comité direction) ● Pour qu'une communauté soit équilibrée, les individus doivent être de provenance variée (usagers et devs, entreprises et organismes multiples, etc.)
  27. 27. Acteurs / Communauté LLO Contributeurs réguliers “Power users” Comité de direction Committeurs
  28. 28. Acteurs / Communauté LLO ● Comité de direction et “committeurs” ● Deux éléments essentiels. On y reviendra plus tard ● Contributeurs réguliers et “Power users” ● C'est la future relève du projet, il faut les accompagner et en prendre soin! ● Traiter tous les usagers comme des contributeurs potentiels ● Un projet LLO puise sont énergie au sein de sa communauté (contributeurs, retours des usagers, financement de nouvelles idées, promotion, etc.). Une communauté active et en santé est donc un gage de viabilité d'un projet LLO.
  29. 29. Entretenir sa communauté ● Listes/forums de discussion publics: ● Support aux usagers ● Annonces ● Planification des révisions, suivis du développement et prise de décisions en public ● Site Web: ● À jour et contenant des références claires à la licence du projet, documentation, dernière révision stable, forums/listes de support et instructions pour contribuer ● Rencontres d'usagers, conférences (ex: FOSS4G) ● “Code Sprint” (excellent pour les contributeurs)
  30. 30. Infrastructure technique d'un projet LLO
  31. 31. Licence Programme Code Source Documentation d'utilisation Infrastructure technique LLO Site Web “Packaging” Dépot de code source Liste Forums IRC Wiki Suite de tests “Bug tracker” Intégration continue
  32. 32. Dépôt de code source ● Utiliser un logiciel de gestion de versions (svn, git, ou autre) ● C'est l'outil de travail quotidien du développeur (imaginez un menuisier sans marteau) ● Permet de conserver un historique des modifications, gérer la provenance du source, et de faciliter la collaboration entre développeurs et la gestion des révisions du logiciel (branches) ● Ne pas se limiter à la gestion du code source, mais aussi inclure la documentation, le contenu du site Web, les autres documents de projet
  33. 33. Site Web ● Le point d'entrée principal du projet, doit être convivial et maintenu à jour Parce qu'on n'a jamais une deuxième chance de faire une bonne première impression. ● Doit permettre de facilement retrouver: ● Une introduction au projet claire et concise (page d'entrée) ● Licence du projet ● Documentation et tutoriels ● Version stable courante (téléchargement et dépôt de code source) ● Options de support/communication: listes, forums, IRC, ainsi que fournisseurs de services privés ($) s'il y a lieu ● Instruction permettant de contribuer au projet
  34. 34. Wiki ● Site Web collaboratif ● Permet le développement de documents en mode collaboratif, ou de documentation préliminaire avant l'intégration dans la documentation officielle ● Permet aux usagers de contribuer et partager des recettes, etc. ● Note: souvent victime de “spam”
  35. 35. Listes, Forums, IRC ● Ce sont les principaux canaux de communication du projet avec sa communauté. ● Assurer une présence active des développeurs du projet favorisera la croissance de la communauté ● Favoriser la communication ouverte et respectueuse ● Utilisations: ● Support aux usagers ● Annonces ● Planification des révisions, suivis du développement et prise de décisions en public
  36. 36. “Bug tracker” ● Permet un suivi efficace des résolutions de bogues et autres changements au logiciel ● Peut être un outil autonome (ex: Trac, Bugzilla) ou faire partie d'une suite plus complète d'outils (ex: Github, Redmine, JIRA, etc.) ● Veiller à ce qu'il s'intègre bien avec le logiciel de gestion de versions du code source afin de permettre des références croisées entre le source et les bugs
  37. 37. Suite de tests ● Utiliser un outil de gestion de tests automatisé en fonction du langage de programmation et de l'environnement de développement ● Permet d'assurer l'intégrité de l'application suite aux changements des committeurs ● Rassure les développeurs en leur permettant de valider rapidement et proactivement que leurs changements n'introduisent pas d'effets de bords ailleurs dans le logiciel ● Peut être combiné à un outil d'analyse du taux de couverture du code source par les tests ● Ex: MapServer utilise les outils gcov et lcov, voir https://github.com/mapserver/coverage
  38. 38. Intégration continue ● Exécute la suite de tests automatiquement à chaque “commit” ou “pull request” et rapporte les échecs immédiatement via courriel, IRC ou autre ● Assure l'intégrité du code source en tout temps ● Ex: MapServer utilise Travis CI, voir https://travis-ci.org/tbonfort/mapserver/
  39. 39. “Packaging” ● Pour faciliter l'adoption et l'installation du logiciel ● Parce que les usagers n'ont pas tous la capacité (ou le désir) de compiler du code source ● Peut prendre différentes formes selon le type de logiciel et les plateformes supportées. Ex: ● Installeur Windows ou OSX ● Paquets sous Linux (deb, rpm, etc.) ● Paquet binaire à télécharger (.zip ou .tar.gz) ● Paquet de code source (JavaScript, Python, etc.)
  40. 40. Processus de gestion d'un projet LLO
  41. 41. Processus de gestion LLO ● Gouvernance ● Mécanisme de décision ● Comité directeur ● Comité technique ● Statut de “committeur” ● Contributeurs ● Gestion des changement (RFC) ● Gestion des révisions
  42. 42. Mécanismes de décision
  43. 43. Mécanisme de décision ● En priorité: Discussion ouverte et recherche de consensus ● Utiliser la liste publique en tout temps (sauf cas extrêmes exigeant confidentialité) ● Dans 99% des cas, le vote sert seulement à confirmer le consensus et officialiser la décision ● Mécanisme de vote: +1, 0, -1 ● Voir RFC 23 MapServer: http://mapserver.org/development/rfc/ms-rfc-23.htm
  44. 44. Mécanisme de vote ● Chaque membre du comité a droit à un vote ● Les motions et votes se font en public sur la liste de discussion (ex: mapserver-dev) ● Le vote est habituellement ouvert pour 2 jours ouvrables sauf exception ● Vote +1, 0, -1: ● +1: Je suis d'accord et m'engage à supporter cette décision et collaborer à sa réalisation ● 0: Abstention, sans effet (aussi sans effet: -0 légèrement en désaccort et +0 légèrement d'accord mais avec des doutes) ● -1: Objection, veto, doit fournir une avenue de solution alternative
  45. 45. Mécanisme de vote ● Une proposition est acceptée si elle reçoit au moins +2 (incluant l'auteur) et aucun veto (-1) ● Si une propostion reçoit un veto (-1) et qu'il est impossible de satisfaire toutes les parties après révision et discussion: ● La proposition peut être soumise pour un second vote ultime ● Dans ce cas un vote +1 de la majorité absolue de tous les membres du comité est requis pour que la proposition soit acceptée (et non pas seulement la majorité des votes soumis) ● Le résultat du vote est compilé et publié par son auteur et archivé sur la liste de discussion et dans les documents associés s'il y a lieu (RFC)
  46. 46. Comité directeur
  47. 47. Comité directeur ● Autorité ultime du projet ● Responsabilités: ● Assigner des ressources au projet ● Entériner les conventions et politiques de travail du projet ● Entériner la vision générale du produit (feuille de route) ● Relation avec le comité de gouverne, les ministères et le monde extérieur du projet ● Définir les priorités du projet, conjointement avec le comité technique ● Rapport annuel du projet au comité de gouverne
  48. 48. Comité technique
  49. 49. Comité technique (1/3) ● Gestion technique de tous les aspects du projet ● Processus de décision (consensus + vote) ● Provenance variée et équilibrée des membres ● Usagers vs contributeurs vs committeur ● Éviter qu'un seul organisme ou entreprise domine le comité ● Viser 5 ou 7 membres au démarrage pour un bon équilibre et permettre l'expansion (le PSC de MapServer a aujourd'hui 14 membres)
  50. 50. Comité technique (2/3) ● Président (“chair”) élu parmi les membres du comité ● Voir MapServer RFC 23: ● http://mapserver.org/development/rfc/ms-rfc-23.html ● Relève du comité directeur ● Responsabilités: ● Conventions et politiques de travail du projet ● Vision générale du produit (feuille de route) ● Gestion des droits d'accès aux services
  51. 51. Comité technique (3/3) ● Responsabilités (suite): ● Coordonner la publication de révisions régulières du logiciel (plan de livraison) ● Réviser et approuver les demandes de changement (RFC) ● Gestion de l'infrastructure du projet (git/svn, site web, etc) (sera éventuellement prise en charge par la forge gouvernementale) ● Gestion des statuts de committeurs ● Définir les priorités du projet, conjointement avec le comité directeur ● Rapport annuel du projet au comité directeur
  52. 52. Comité technique ● Élection de nouveaux membres ● Au besoin, ou lorsqu'on bon candidat se démarque, il peut être nominé et élu par motion et vote +1 de la majorité absolue des membres existants ● Démission, renvoi: ● Un membre peut démissionner en tout temps ● Un membre inactif pour une période prolongée (aucune participation aux votes, réunions et autres activités du comité) peut être remplacé par vote des autres membres du comité
  53. 53. Statut de “Committeur”
  54. 54. Statut de “committeur” (1/4) ● Privilège: ● Permission de contribuer au dépôt de code source directement ● Responsabilités: ● signer et respecter l'entente de contribution (voir http://wiki.osgeo.org/wiki/Contributor_Agreement (bugs, etc.) ● respecter les règles d'engagement (RFC 7.1) ● signer et respecter l'entente de contribution (voir http://wiki.osgeo.org/wiki/Contributor_Agreement)
  55. 55. Statut de “committeur” (2/4) ● Le comité technique du projet vote et approuve l'élection de nouveaux “committeurs” et gère/active les droits dans le dépôt de code source (git, svn , etc.) ● Un “committeur” inactif ou qui ne respecte pas les règles d'engagement peut se faire révoquer son titre/droit de “committeur”
  56. 56. Statut de “committeur” (3/4) ● Comment y accéder? ● Commencer par contribuer régulièrement des “patch” via le “bug tracker” ● Un/des “committeurs” vont réviser et endosser ces “patch” pour inclusion officielle dans le logiciel ● Répéter jusqu'à ce que vous ayez gagné la confiance des autres “committeurs” ● Confirmer votre désir de devenir “committeur” et de respecter les règles d'engagement ● À ce moment une motion sera faite au comité technique du projet qui passera au vote afin de vous attribuer le titre de committeur
  57. 57. Statut de “committeur” (4/4) ● Comment gagner la confiance des autres “committeurs”? ● Bonne compréhension de l'architecture, des outils et méthodes de fonctionnement du projet ● Code de qualité ● Aptitudes de communication ● Intention de rester actif à moyen-long terme ● Pourrait passer à travers une formation ou “examen par les pairs” pour devenir “committeur” plus rapidement
  58. 58. Règles d'engagement du “committeur”
  59. 59. Entente de contribution (1/2) ● Vise à protéger l'intégrité du code source du logiciel contre les contributions illégitimes, accidentelles ou non, et leurs conséquences ● Engagement légal du “committeur” envers le projet, confirmant qu'il a le droit de contribuer sa PI au projet ● Doit être signée par tous les “committeurs” ou contributeurs réguliers ● Peut ou non inclure un transfert de droit d'auteur
  60. 60. Entente de contribution (2/2) ● Selon les cas, une entente individuelle et corporative peuvent être requises (si l'employeur possède les droits sur le travail de l'employé) ● Voir: http://wiki.osgeo.org/wiki/Contributor_Agreement
  61. 61. Convention de codage et règles de conduite des committeurs ● Visent l'uniformité du code et des méthodes de travail, ex: ● Règles d'écriture de code source ● Règles d'architecture, du modèle de données ● À respecter par le commiteur, pré-requis à toute contribution ● Voir MapServer RFC 7.1 ● http://mapserver.org/development/rfc/ms-rfc-7.1.html
  62. 62. Contributeurs ● Utiliser “contributeur” pour être plus inclusif. ● Les contributeurs incluent: ● Développeurs ● Architectes ● Rédacteurs de documentation ● Testeurs/valideurs ● Pilotes/usagers du système ● Tout autre type de contribution
  63. 63. Gestion des changements (RFC)
  64. 64. Gestion des changements (1/2) ● Processus de demande de changement (RFC): ● Discussions préliminaires sur la liste -dev ● Production d'un document RFC dans le dépot de RFC du projet (qui, quand, quoi, pourquoi, comment, incompatibilités, etc) ● Discussion du RFC ● Vote du comité technique ● Auteur de la RFC réflète le résultat du vote dans le document ● Implémentation, documentation, etc.
  65. 65. Gestion des changements (2/2) ● Liste des RFCs disponible sur le site Web (ou autre dépot) ● Le projet devrait se définir un gabarit de RFC
  66. 66. Gestion des révisions
  67. 67. Gestion des révisions ● Exemple de MapServer, voir RFC-34 ● http://mapserver.org/development/rfc/ms-rfc-34.html ● Dépot d'un plan de livraison ● Rôle de responsable de livraison (doit être commmiteur) ● Cycle de révisions – Cycle de +/- 6 mois entre les révisions, ou basé sur feuille de route (“roadmap”) – Dév. -> Plan livraison -> Gel de fonctionnalités -> betas -> RC -> livraison
  68. 68. Gestion des révisions ● Numérotage des révisions (MapServer) ● Version = x.y.z (majeur.mineur.patch) ● Mineur paire = stable (ex: 5.4, 5.6) ● Mineur impaire = développement (ex: 5.5) ● Patch = résolutions bogues seul. = 5.4.1, 5.4.2, etc. ● Voir aussi “semantic versioning” ● http://semver.org/
  69. 69. Branchement du code source ● Multiples stratégies possibles ● Exemple: http://www.liquibase.org/development/branches.html
  70. 70. Exemples d'application des processus
  71. 71. Mise en place d'un comité technique
  72. 72. Mise en place d'un comité technique (1/2) ● S'associer un mentor pour vous accompagner s'il y a lieu ● Nombre de membres idéal au démarrage: 5 ou 7 membres ● Identifier une liste de candidats potentiels: ● Le premier candidat est le fondateur du projet, évidemment ● Regarder parmi les “power users” et les contributeurs actuels ou contributeurs potentiels à court terme
  73. 73. Mise en place d'un comité technique (2/2) ● En provenance de multiples organismes et entreprises ● Représentation diversifiée de tous les acteurs du milieu (instutitionnel, privé, éducation, usagers, développeurs, rédacteurs de docs, multiples régions géographiques, etc.) ● Pas besoin d'être programmeur, mais un minimum de connaissances techniques et/ou du domaine d'affaires est requise ● Les candidats doivent avoir le projet à coeur (les raisons peuvent varier) et la volonté d'y mettre un peu de temps
  74. 74. Mise en place d'un comité technique ● Communiquer avec chacun des candidats pour ● Partager vos intentions de publier votre projet en LLO ● Sonder et confirmer leur intérêt de participer au comité de direction ● Les inviter à une rencontre de pré-démarrage
  75. 75. Mise en place d'un comité technique ● Planifier la rencontre de pré-démarrage ● Se préparer à expliquer les principes de gestion LLO si les candidats ne les connaissent pas déjà ● Préparer une ébauche de règles d'opération du comité pour base de discussion (s'inspirer d'un autre projet mature, ex: MapServer) ● Infrastructure LLO: on peut préparer une ébauche, mais se rappeler que ce sera une des premières tâches du comité de direction de régler ces détails ● Se préparer mentalement au fait qu'à partir du début de cette rencontre on n'est plus le seul maître et on doit viser des consensus forts si on veut former un comité fort. ● Bref, rien dans votre ébauche de comité n'est coulé dans le béton, tous les points sont à discuter avec les candidats invités
  76. 76. Mise en place d'un comité technique ● Rencontre de pré-démarrage – ordre du jour ● Mot de bienvenue, mise en situation ● Tour de table, présentation des candidats invités ● Présentation du projet LLO et de vos intentions – Rappeler l'intention de passer les pouvoirs au comité de direction – Rappeler que tout est sujet à discussion et consensus ● Présentation des principes de gestion LLO (s'il y a lieu) ● Présentation et discussion de l'ébauche de règles d'opération ● Formation officielle du comité – Tous les candidats ont l'option d'embarquer ou non – La formation officielle pourrait être reportée à une autre rencontre si du travail reste à faire ou des candidats veulent une période de réflexion – Élire un président parmi les membres – Convenir de la date de début des activités / passation des pouvoirs
  77. 77. Mise en place d'un comité technique ● Rencontres de pré-démarrages multiples si nécessaire ● Exécution des décisions ● Compiler la version finale des règles d'opération du comité de direction ● Compiler la liste finale des membres du comité ● Partager le tout avec les membres pour approbation ● Planifier le début des activités du comité selon ce qui a été convenu lors de la rencontre
  78. 78. Mise en place d'un comité technique ● Première réunion du comité ● Démarrage officiel ● Passation des pouvoirs du fondateur vers le comité ● Décisions face à l'infrastructure de projet LLO ● Publication des minutes des réunions sur le site Web si elles ont lieu face à face ● Confirmer/diffuser les décisions du comité sur la liste de discussions pour le bénéfice de la communauté
  79. 79. Mise en place d'un comité technique ● Et voilà! Longue vie au projet et à son comité! ● Dans les premiers temps le comité devra mettre en place tous les éléments requis par le projet LLO ● Défi d'adaptation à un environnement distribué: ● éviter les réunions face à face puisqu'elles sont en contradiction du principe d'implication active de la communauté dans le projet ● favoriser les échanges par courriel sur la liste de discussions du projet ou les réunions virtuelles permettant à tous les membres du comité de participer facilement et aux intéressés dans la communauté de participer en tant qu'observateur ● Les réunions IRC fonctionnent bien pour OSGeo
  80. 80. Ajout d'une fonctionnalité au logiciel
  81. 81. Ajout d'une fonctionnalité au logiciel ● Un usager exprime un besoin ● Un développeur accepte de le prendre en charge ● (pour des raisons $$, altruistes ou autre) ● Le besoin et les solutions possibles sont discutés sur la liste de discussion -dev afin de valider les solutions potentielles et la réceptivité des autres développeurs à cet ajout ● Le développeur écrit un RFC (1 à 3 pages) décrivant le besoin, la nouvelle fonctionnalité, la solution proposée et les détails d'implémentation, les impacts potentiels, des exemples d'utilisation, etc
  82. 82. Ajout d'une fonctionnalité au logiciel ● Le RFC est soumis pour discussion au comité de direction pour une période de 2 à 5 jours ouvrables ● Des ajustements sont faits en fonction des commentaires ● Le comité de direction passe au vote pour adoption du RFC ● Si le RFC est adopté, le développeur peut procéder, sinon il retourne à la table à dessin (ou choisit d'abandonner le projet)
  83. 83. Ajout d'une fonctionnalité au logiciel ● Le développeur implémente la nouvelle fonctionnalité tel que décrit dans le RFC ● Code source ● Tests ● Documentation ● S'il est “committeur”, il peut faire le “commit” une fois terminé ● Sinon il doit soumettre une “patch” via le “bug tracker” (ou un “pull request” avec Github) et espérer qu'un “committeur” veuille bien réviser/endosser son code et le “committer” pour lui ● La nouvelle fonctionnalité est maintenant dans le dépôt de code source, en attente de la prochaine révision officielle du logiciel
  84. 84. Production d'une révision de logiciel
  85. 85. Production d'une révision de logiciel ● Le temps est venu de publier une nouvelle “release” du logiciel ● Un “Release Plan” est publié – Un “Release manager” est nommé pour cette révision – Date de “Feature Freeze” – Date de “release” prévue – Liste des fonctionnalités majeures incluses ● Le comité de direction vote pour accepter le “release plan” ● Le processus de “release” est enclanché
  86. 86. Production d'une révision de logiciel ● “Release Manager” ● Responsable de l'exécution du “release plan” – Coordination et respect des échéanciers – Rappel et respect du “feature freeze” – Paquetage et annonce des beta et révisions finales – Autorité ultime en cas de doute/conflit sur l'admissibilité de certains changements dans la révision – Responsable des “patch release” pour les mois suivant la révision finale
  87. 87. Production d'une révision de logiciel ● “Feature Freeze” ● Date à partir de laquelle aucun changement majeur au code source n'est permis ● On tombe en mode stabilisation du code source ● Résolution de bogues seulement ● Marque le début des betas menant à la révision finale
  88. 88. Production d'une révision de logiciel ● Multiples betas ● De multiples betas sont publiés espacés de 1-2 semaines afin de permettre aux usagers de tester ● 4-5 betas habituellement sur une période de 6 a 8 semaines ● Lorsque le niveau de stabilité voulu est atteint on produit un “Release Candidate” ● Si aucun bogue majeur dans le “Release Candidate” il devient la révision finale officielle ● Sinon on produit un nouveau RC jusqu'à ce qu'on ait le bon
  89. 89. Production d'une révision de logiciel ● Révision finale (tâches du “Release manager”): ● Paquetage du code source ● Publication du code source sur le site de téléchargements ● Publication d'une annonce à la communauté ● Mise à jour du site Web pour refléter la nouvelle révision ● Création d'une “branche stable” dans le dépot de code source. ● Le “Feature Freeze” est levé, les développements peuvent reprendre dans le tronc principal du dépôt de code source ● En parallèle, les producteurs de distributions binaires s'activent et publient des exécutables de la nouvelle révision
  90. 90. Autres considérations
  91. 91. Convertir un projet interne en LLO? Une décision importante ● Avantages ● Attirer de nouveaux usagers et surtout contributeurs pour une croissance accrue du logiciel (coopérer avec d'autres experts à travers le monde au lieu de compétitionner avec eux) ● Bénéficier du retour de la communauté (nouvelles fonctionnalités, bug fix, tests, docs, etc.) ● Augmenter la viabilité long terme du logiciel (“bus number”, survie au départ du créateur original) ● Désavantages ● Perte de contrôle partielle du créateur original sur le projet (le comité de direction prend le contrôle) ● Perte potentielle d'un avantage compétitif?
  92. 92. Convertir un projet interne en LLO? Une décision importante ● Questions importantes ● A-t-on la capacité d'attirer une communauté suffisamment grande pour générer un retour significatif? ● Comment financer nos activités de support du projet LLO? ● Est-on prêts à jouer le jeu et accepter la perte de contrôle partielle sur la vision et direction du projet? ● Est-on prêts à travailler en mode distribué (pourrait demander une adaptation si l'équipe était 100% locale auparavant) ● Choix de licence stratégique – Réciproque (GPL, etc.): assure que le code demeure libre mais risque de faire reculer certains utilisateurs / contributeurs potentiels (ex: revendeurs de produit à valeur ajoutée) – Non-réciproque (MIT, BSD, Apache) moins contraignant, plus propice à l'usage commercial ou par des revendeurs propriétaires
  93. 93. Autres considérations ● Possibilité d'un “Fork” ● Gestion par comité vs “benevolent dictator” ● Révisions de sécurité ● Fournisseurs de services ($) ● Support technique professionnel ● Formation ● Développement de fonctionnalités
  94. 94. Incubateur de LLO
  95. 95. Incubateur ● Voir incubateur OSGeo: http://www.osgeo.org/incubator/ ● Objectif: Vérifier l'intégrité et la viabilité long terme d'un projet LLO avant son admission dans la fondation ● Règles d'admission dans l'incubateur ● Formulaire d'application ● Mentor ● Licence ouverte approuvée par l'OSI ● Potentiel de graduation ● Règles de graduation de l'incubateur (voir “checklist”) ● Aspect légal ● Communauté active et équilibrée ● Gestion ouverte et Développement ouvert
  96. 96. Incubateur – Critères de graduation (“Checklist”) (1/3) ● Aspect légal: ● Licence ouverte approuvée par l'OSI (opensource.org) ● Validation de la provenance du code source ● Ententes de contribution, signée par tous les committeurs ● Communauté active et équilibrée ● Communauté active et équilibrée d'usagers et contributeurs (subjectif, signe de viabilité long terme) ● Mécanismes de communication ouverts en utilisation (site Web, listes, forums)
  97. 97. Incubateur – Critères de graduation (“Checklist”) (2/3) Gestion ouverte ● Mécanisme de gestion et de décision ouverts et documentés ● Comité de direction ● Statut de “comitteur” ● Mécanisme ouvert d'ajout de membres au comité de direction et committeurs
  98. 98. Incubateur – Critères de graduation (“Checklist”) (3/3) ● Développement ouvert ● Méthodes de développement ouvertes et documentées ● Infrastructure LLO minimale (Dépot code source, site Web, bug tracker, liste discussion) ● Gestion des changements (RFC) ● Processus de révision ● Convention de codage / “committer guidelines”
  99. 99. Comité d'incubation (ex: OSGeo) (1/3) ● Gestion de l'incubateur: ● Responsable de l'admission des projets dans l'incubateur ● Responsable de l'évaluation avant graduation ● Responsable de la mise à jour et évolution des règles de graduation lorsque nécessaire ● Règles d'opérations du comité simiaires au comité de direction d'un projet LLO ● Les membres du comité sont des anciens mentors ou mentors potentiels (expérience requise)
  100. 100. Comité d'incubation (ex: OSGeo) (2/3) ● Processus d'incubation type: ● Un projet applique auprès de l'incubateur (formulaire d'application) ● Comité incubation évalue la demande et vote ● Si admis, alors le mentor assiste le projet pour évaluer et faire les ajustements nécessaires pour rencontrer tous les critères de graduation (le mentor ne fait pas le travail, il est seulement un guide, ce sont les membres du projet qui font le travail) ● Un rapoort d'avancement est tenu à jour pour suivre le progrès (wiki) ● Lorsque le mentor juge que le projet a rempli tous les critères, il soumet une motion au comité incubation pour proposer la graduation du projet
  101. 101. Comité d'incubation (ex: OSGeo) (3/3) ● Processus d'incubation type (suite): ● Les membres du comité incubation ont une semaine pour réviser le rapport de progrès ● Des ajustements sont habituellements proposés pendant la période d'évaluation ● Une fois tous les commentaires adressés, le comité passe au vote ● Si le vote est positif, le projet est “gradué”t. Une recommandation d'admission officielle est transmise au CA (“board”) de la fondation ● Si le vote est négatif, alors le projet doit faire les correctifs nécessaires et revenir pour une nouvelle demande de graduation plus tard
  102. 102. Liens utiles
  103. 103. Liens utiles● Producing Open Source Software ● http://producingoss.com/ ● How to maintain a successful open source project ● https://medium.com/p/aaa2a5437d3a ● Règles d'opération du comité de direction MapServer (RFC 23): ● http://mapserver.org/development/rfc/ms-rfc-23.html ● Règles d'engagement des “committeurs” MapServer (RFC 7.1): ● http://mapserver.org/development/rfc/ms-rfc-7.1.html ● Processus de gestion de révisions de MapServer (RFC 34) ● http://mapserver.org/development/rfc/ms-rfc-34.html ● Semantic Versioning ● http://semver.org/ ● Ententes de contribution OSGeo: ● http://wiki.osgeo.org/wiki/Contributor_Agreement ● Incubateur OSGeo ● http://www.osgeo.org/incubator/ ● http://www.osgeo.org/incubator/process/project_graduation_checklist.html

×