1. Atelier Dveloppement et gestion de Logiciel Libre et Ouvert (LLO) 25 juillet 2013 Daniel Morissette dmorissette@mapgears.com

2. Daniel Morissette Prsident, Mapgears Inc Bac Gnie informatique, UQAC, 1994 Dv. de logiciel libre et ouvert et membre de comits de direction: GDAL/OGR (1998+) MapServer (2000+) Dmarrage et contribution plusieurs autres projets LLO Fondation OSGeo Charter member (2006+) Board of directors (2010+) et trsorier (2011+) Chapitre local OSGeo-Qubec (2008+) Prix Sol Katz en 2009 Incubateur OSGeo: 3x mentor (MapGuide Open Source, FDO, MetaCRS) chair du comit incubation en 2011 3. Fondations LLO 4. Dveloppement / gestion de LLO Introduction Acteurs / Communaut LLO Infrastructure technique Processus de gestion Exemples d'application des processus Autres considrations Incubateur Liens utiles 5. Introduction 6. Libre ou Open Source? L'Open Source est une mthodologie de dveloppement (motivations pratiques) Le Libre est un mouvement social (motivations thiques) Les motivations diffrent mais les deux groupes se rejoignent sur la solution 7. Qu'est-ce qu'un logiciel? 8. Logiciel * Image courtoisie de Master isolated images / FreeDigitalPhotos.net 9. Logiciel libre et ouvert Licence Programme Code Source Documentation d'utilisation 10. Logiciel propritaire Licence Programme EXE Documentation d'utilisation 11. 11 Les licences 12. Dfinition d'une licence libre Une licence libre ou ouverte doit garantir les 4 liberts suivantes: d'utiliser de copier d'tudier de modifier et redistribuer 13. Catgories de licences 14. 14 Licences Obligations ??? L'utilisation de code Open Source dans votre application vous oblige a) retourner vos modifications/amliorations au projet OS correspondant b) publier l'ensemble de votre code source sous la mme licence c) aucune obligation de publication dialog-question.png: Human-O Icon Set (c) Olivier Scholtz and others 15. 15 Licences GPL LGPL MIT/X BSD Rciproque (copyleft) Non-rciproque 16. 16 Licences Le choix de la licence est trs important. C'est une dcision stratgique (vs rciprocit ou non) qui doit tre faite en dbut de projet Avec une licence libre/ouverte, on ne cde pas sa proprit intellectuelle, on l'utilise pour rendre le code libre 17. 17 Modle de fonctionnement diteur propritaire vs Projet LLO 18. Modle de l'diteur propritaire * Image courtoisie supercoloring.com $ $ $$ $ $ $ $ $ Direction R&D Marketing RH ... Prod. Mgr, devs, docs, QA, etc $ $ $$ $ $ $ $ $ 19. Modle du projet LLO (Mythe) Image: Paul Ramsey, Beyond Nerds Bearing Gifts, The future of the Open Source Economy 20. Modle du projet LLO Communaut ( la fois conepteur, gestionnaire et utilisateur) 21. Modle du projet LLO Communaut ( la fois conepteur, gestionnaire et utilisateur) 22. Modle du projet LLO Communaut ( la fois conepteur, gestionnaire et utilisateur) 23. Modle du projet LLO Communaut ( la fois conepteur, gestionnaire et utilisateur) 24. Modle du projet LLO Les membres de la communaut agissent titre individuel, mme s'ils sont pays par un employeur Les entreprises et organismes sont bienvenus mais n'ont pas de statut spcial au sein de la communaut, ils sont reprsents par des individus La communaut d'un LLO mature a des rgle de fonctionnement claires que nous allons dcouvrir 25. Acteurs / Communaut LLO 26. Acteurs / Communaut LLO Usagers (de dbutants power users) Contributeurs actifs: Dveloppeurs, architectes Rdacteurs de docs, traducteurs, graphistes, etc Autres contributeurs, testeurs (rguliers ou intermittents) Statuts spciaux: Membres du comit de direction Committeur Les individus peuvent jouer plusieurs rles (ex: un usager, peut tre aussi contributeur et membre du comit direction) Pour qu'une communaut soit quilibre, les individus doivent tre de provenance varie (usagers et devs, entreprises et organismes multiples, etc.) 27. Acteurs / Communaut LLO Contributeurs rguliers Power users Comit de direction Committeurs 28. Acteurs / Communaut LLO Comit de direction et committeurs Deux lments essentiels. On y reviendra plus tard Contributeurs rguliers et Power users C'est la future relve 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 ides, promotion, etc.). Une communaut active et en sant est donc un gage de viabilit d'un projet LLO. 29. Entretenir sa communaut Listes/forums de discussion publics: Support aux usagers Annonces Planification des rvisions, suivis du dveloppement et prise de dcisions en public Site Web: jour et contenant des rfrences claires la licence du projet, documentation, dernire rvision stable, forums/listes de support et instructions pour contribuer Rencontres d'usagers, confrences (ex: FOSS4G) Code Sprint (excellent pour les contributeurs) 30. Infrastructure technique d'un projet LLO 31. Licence Programme Code Source Documentation d'utilisation Infrastructure technique LLO Site Web Packaging Dpot de code source Liste Forums IRC Wiki Suite de tests Bug tracker Intgration continue 32. Dpt de code source Utiliser un logiciel de gestion de versions (svn, git, ou autre) C'est l'outil de travail quotidien du dveloppeur (imaginez un menuisier sans marteau) Permet de conserver un historique des modifications, grer la provenance du source, et de faciliter la collaboration entre dveloppeurs et la gestion des rvisions 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. Site Web Le point d'entre principal du projet, doit tre convivial et maintenu jour Parce qu'on n'a jamais une deuxime chance de faire une bonne premire impression. Doit permettre de facilement retrouver: Une introduction au projet claire et concise (page d'entre) Licence du projet Documentation et tutoriels Version stable courante (tlchargement et dpt de code source) Options de support/communication: listes, forums, IRC, ainsi que fournisseurs de services privs ($) s'il y a lieu Instruction permettant de contribuer au projet 34. Wiki Site Web collaboratif Permet le dveloppement de documents en mode collaboratif, ou de documentation prliminaire avant l'intgration dans la documentation officielle Permet aux usagers de contribuer et partager des recettes, etc. Note: souvent victime de spam 35. Listes, Forums, IRC Ce sont les principaux canaux de communication du projet avec sa communaut. Assurer une prsence active des dveloppeurs du projet favorisera la croissance de la communaut Favoriser la communication ouverte et respectueuse Utilisations: Support aux usagers Annonces Planification des rvisions, suivis du dveloppement et prise de dcisions en public 36. Bug tracker Permet un suivi efficace des rsolutions de bogues et autres changements au logiciel Peut tre un outil autonome (ex: Trac, Bugzilla) ou faire partie d'une suite plus complte d'outils (ex: Github, Redmine, JIRA, etc.) Veiller ce qu'il s'intgre bien avec le logiciel de gestion de versions du code source afin de permettre des rfrences croises entre le source et les bugs 37. Suite de tests Utiliser un outil de gestion de tests automatis en fonction du langage de programmation et de l'environnement de dveloppement Permet d'assurer l'intgrit de l'application suite aux changements des committeurs Rassure les dveloppeurs 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. Intgration continue Excute la suite de tests automatiquement chaque commit ou pull request et rapporte les checs immdiatement via courriel, IRC ou autre Assure l'intgrit du code source en tout temps Ex: MapServer utilise Travis CI, voir https://travis-ci.org/tbonfort/mapserver/ 39. Packaging Pour faciliter l'adoption et l'installation du logiciel Parce que les usagers n'ont pas tous la capacit (ou le dsir) de compiler du code source Peut prendre diffrentes formes selon le type de logiciel et les plateformes supportes. Ex: Installeur Windows ou OSX Paquets sous Linux (deb, rpm, etc.) Paquet binaire tlcharger (.zip ou .tar.gz) Paquet de code source (JavaScript, Python, etc.) 40. Processus de gestion d'un projet LLO 41. Processus de gestion LLO Gouvernance Mcanisme de dcision Comit directeur Comit technique Statut de committeur Contributeurs Gestion des changement (RFC) Gestion des rvisions 42. Mcanismes de dcision 43. Mcanisme de dcision En priorit: Discussion ouverte et recherche de consensus Utiliser la liste publique en tout temps (sauf cas extrmes exigeant confidentialit) Dans 99% des cas, le vote sert seulement confirmer le consensus et officialiser la dcision Mcanisme de vote: +1, 0, -1 Voir RFC 23 MapServer: http://mapserver.org/development/rfc/ms-rfc-23.htm 44. Mcanisme 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 dcision et collaborer sa ralisation 0: Abstention, sans effet (aussi sans effet: -0 lgrement en dsaccort et +0 lgrement d'accord mais avec des doutes) -1: Objection, veto, doit fournir une avenue de solution alternative 45. Mcanisme de vote Une proposition est accepte si elle reoit au moins +2 (incluant l'auteur) et aucun veto (-1) Si une propostion reoit un veto (-1) et qu'il est impossible de satisfaire toutes les parties aprs rvision 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 accepte (et non pas seulement la majorit des votes soumis) Le rsultat du vote est compil et publi par son auteur et archiv sur la liste de discussion et dans les documents associs s'il y a lieu (RFC) 46. Comit directeur 47. Comit directeur Autorit ultime du projet Responsabilits: Assigner des ressources au projet Entriner les conventions et politiques de travail du projet Entriner la vision gnrale du produit (feuille de route) Relation avec le comit de gouverne, les ministres et le monde extrieur du projet Dfinir les priorits du projet, conjointement avec le comit technique Rapport annuel du projet au comit de gouverne 48. Comit technique 49. Comit technique (1/3) Gestion technique de tous les aspects du projet Processus de dcision (consensus + vote) Provenance varie et quilibre des membres Usagers vs contributeurs vs committeur viter qu'un seul organisme ou entreprise domine le comit Viser 5 ou 7 membres au dmarrage pour un bon quilibre et permettre l'expansion (le PSC de MapServer a aujourd'hui 14 membres) 50. Comit technique (2/3) Prsident (chair) lu parmi les membres du comit Voir MapServer RFC 23: http://mapserver.org/development/rfc/ms-rfc-23.html Relve du comit directeur Responsabilits: Conventions et politiques de travail du projet Vision gnrale du produit (feuille de route) Gestion des droits d'accs aux services 51. Comit technique (3/3) Responsabilits (suite): Coordonner la publication de rvisions rgulires du logiciel (plan de livraison) Rviser 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 Dfinir les priorits du projet, conjointement avec le comit directeur Rapport annuel du projet au comit directeur 52. Comit technique lection de nouveaux membres Au besoin, ou lorsqu'on bon candidat se dmarque, il peut tre nomin et lu par motion et vote +1 de la majorit absolue des membres existants Dmission, renvoi: Un membre peut dmissionner en tout temps Un membre inactif pour une priode prolonge (aucune participation aux votes, runions et autres activits du comit) peut tre remplac par vote des autres membres du comit 53. Statut de Committeur 54. Statut de committeur (1/4) Privilge: Permission de contribuer au dpt de code source directement Responsabilits: signer et respecter l'entente de contribution (voir http://wiki.osgeo.org/wiki/Contributor_Agreement (bugs, etc.) respecter les rgles d'engagement (RFC 7.1) signer et respecter l'entente de contribution (voir http://wiki.osgeo.org/wiki/Contributor_Agreement) 55. Statut de committeur (2/4) Le comit technique du projet vote et approuve l'lection de nouveaux committeurs et gre/active les droits dans le dpt de code source (git, svn , etc.) Un committeur inactif ou qui ne respecte pas les rgles d'engagement peut se faire rvoquer son titre/droit de committeur 56. Statut de committeur (3/4) Comment y accder? Commencer par contribuer rgulirement des patch via le bug tracker Un/des committeurs vont rviser et endosser ces patch pour inclusion officielle dans le logiciel Rpter jusqu' ce que vous ayez gagn la confiance des autres committeurs Confirmer votre dsir de devenir committeur et de respecter les rgles 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. Statut de committeur (4/4) Comment gagner la confiance des autres committeurs? Bonne comprhension de l'architecture, des outils et mthodes 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. Rgles d'engagement du committeur 59. Entente de contribution (1/2) Vise protger l'intgrit du code source du logiciel contre les contributions illgitimes, accidentelles ou non, et leurs consquences Engagement lgal du committeur envers le projet, confirmant qu'il a le droit de contribuer sa PI au projet Doit tre signe par tous les committeurs ou contributeurs rguliers Peut ou non inclure un transfert de droit d'auteur 60. Entente de contribution (2/2) Selon les cas, une entente individuelle et corporative peuvent tre requises (si l'employeur possde les droits sur le travail de l'employ) Voir: http://wiki.osgeo.org/wiki/Contributor_Agreement 61. Convention de codage et rgles de conduite des committeurs Visent l'uniformit du code et des mthodes de travail, ex: Rgles d'criture de code source Rgles d'architecture, du modle de donnes respecter par le commiteur, pr-requis toute contribution Voir MapServer RFC 7.1 http://mapserver.org/development/rfc/ms-rfc-7.1.html 62. Contributeurs Utiliser contributeur pour tre plus inclusif. Les contributeurs incluent: Dveloppeurs Architectes Rdacteurs de documentation Testeurs/valideurs Pilotes/usagers du systme Tout autre type de contribution 63. Gestion des changements (RFC) 64. Gestion des changements (1/2) Processus de demande de changement (RFC): Discussions prliminaires sur la liste -dev Production d'un document RFC dans le dpot de RFC du projet (qui, quand, quoi, pourquoi, comment, incompatibilits, etc) Discussion du RFC Vote du comit technique Auteur de la RFC rflte le rsultat du vote dans le document Implmentation, documentation, etc. 65. Gestion des changements (2/2) Liste des RFCs disponible sur le site Web (ou autre dpot) Le projet devrait se dfinir un gabarit de RFC 66. Gestion des rvisions 67. Gestion des rvisions Exemple de MapServer, voir RFC-34 http://mapserver.org/development/rfc/ms-rfc-34.html Dpot d'un plan de livraison Rle de responsable de livraison (doit tre commmiteur) Cycle de rvisions Cycle de +/- 6 mois entre les rvisions, ou bas sur feuille de route (roadmap) Dv. -> Plan livraison -> Gel de fonctionnalits -> betas -> RC -> livraison 68. Gestion des rvisions Numrotage des rvisions (MapServer) Version = x.y.z (majeur.mineur.patch) Mineur paire = stable (ex: 5.4, 5.6) Mineur impaire = dveloppement (ex: 5.5) Patch = rsolutions bogues seul. = 5.4.1, 5.4.2, etc. Voir aussi semantic versioning http://semver.org/ 69. Branchement du code source Multiples stratgies possibles Exemple: http://www.liquibase.org/development/branches.html 70. Exemples d'application des processus 71. Mise en place d'un comit technique 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 idal au dmarrage: 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. Mise en place d'un comit technique (2/2) En provenance de multiples organismes et entreprises Reprsentation diversifie de tous les acteurs du milieu (instutitionnel, priv, ducation, usagers, dveloppeurs, rdacteurs de docs, multiples rgions gographiques, 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. 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 intrt de participer au comit de direction Les inviter une rencontre de pr-dmarrage 75. Mise en place d'un comit technique Planifier la rencontre de pr-dmarrage Se prparer expliquer les principes de gestion LLO si les candidats ne les connaissent pas dj Prparer une bauche de rgles d'opration du comit pour base de discussion (s'inspirer d'un autre projet mature, ex: MapServer) Infrastructure LLO: on peut prparer une bauche, mais se rappeler que ce sera une des premires tches du comit de direction de rgler ces dtails Se prparer mentalement au fait qu' partir du dbut de cette rencontre on n'est plus le seul matre 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 bton, tous les points sont discuter avec les candidats invits 76. Mise en place d'un comit technique Rencontre de pr-dmarrage ordre du jour Mot de bienvenue, mise en situation Tour de table, prsentation des candidats invits Prsentation 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 Prsentation des principes de gestion LLO (s'il y a lieu) Prsentation et discussion de l'bauche de rgles d'opration Formation officielle du comit Tous les candidats ont l'option d'embarquer ou non La formation officielle pourrait tre reporte une autre rencontre si du travail reste faire ou des candidats veulent une priode de rflexion lire un prsident parmi les membres Convenir de la date de dbut des activits / passation des pouvoirs 77. Mise en place d'un comit technique Rencontres de pr-dmarrages multiples si ncessaire Excution des dcisions Compiler la version finale des rgles d'opration du comit de direction Compiler la liste finale des membres du comit Partager le tout avec les membres pour approbation Planifier le dbut des activits du comit selon ce qui a t convenu lors de la rencontre 78. Mise en place d'un comit technique Premire runion du comit Dmarrage officiel Passation des pouvoirs du fondateur vers le comit Dcisions face l'infrastructure de projet LLO Publication des minutes des runions sur le site Web si elles ont lieu face face Confirmer/diffuser les dcisions du comit sur la liste de discussions pour le bnfice de la communaut 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 lments requis par le projet LLO Dfi d'adaptation un environnement distribu: viter les runions 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 runions virtuelles permettant tous les membres du comit de participer facilement et aux intresss dans la communaut de participer en tant qu'observateur Les runions IRC fonctionnent bien pour OSGeo 80. Ajout d'une fonctionnalit au logiciel 81. Ajout d'une fonctionnalit au logiciel Un usager exprime un besoin Un dveloppeur accepte de le prendre en charge (pour des raisons $$, altruistes ou autre) Le besoin et les solutions possibles sont discuts sur la liste de discussion -dev afin de valider les solutions potentielles et la rceptivit des autres dveloppeurs cet ajout Le dveloppeur crit un RFC (1 3 pages) dcrivant le besoin, la nouvelle fonctionnalit, la solution propose et les dtails d'implmentation, les impacts potentiels, des exemples d'utilisation, etc 82. Ajout d'une fonctionnalit au logiciel Le RFC est soumis pour discussion au comit de direction pour une priode 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 dveloppeur peut procder, sinon il retourne la table dessin (ou choisit d'abandonner le projet) 83. Ajout d'une fonctionnalit au logiciel Le dveloppeur implmente la nouvelle fonctionnalit tel que dcrit 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 esprer qu'un committeur veuille bien rviser/endosser son code et le committer pour lui La nouvelle fonctionnalit est maintenant dans le dpt de code source, en attente de la prochaine rvision officielle du logiciel 84. Production d'une rvision de logiciel 85. Production d'une rvision 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 rvision Date de Feature Freeze Date de release prvue Liste des fonctionnalits majeures incluses Le comit de direction vote pour accepter le release plan Le processus de release est enclanch 86. Production d'une rvision de logiciel Release Manager Responsable de l'excution du release plan Coordination et respect des chanciers Rappel et respect du feature freeze Paquetage et annonce des beta et rvisions finales Autorit ultime en cas de doute/conflit sur l'admissibilit de certains changements dans la rvision Responsable des patch release pour les mois suivant la rvision finale 87. Production d'une rvision 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 Rsolution de bogues seulement Marque le dbut des betas menant la rvision finale 88. Production d'une rvision de logiciel Multiples betas De multiples betas sont publis espacs de 1-2 semaines afin de permettre aux usagers de tester 4-5 betas habituellement sur une priode 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 rvision finale officielle Sinon on produit un nouveau RC jusqu' ce qu'on ait le bon 89. Production d'une rvision de logiciel Rvision finale (tches du Release manager): Paquetage du code source Publication du code source sur le site de tlchargements Publication d'une annonce la communaut Mise jour du site Web pour reflter la nouvelle rvision Cration d'une branche stable dans le dpot de code source. Le Feature Freeze est lev, les dveloppements peuvent reprendre dans le tronc principal du dpt de code source En parallle, les producteurs de distributions binaires s'activent et publient des excutables de la nouvelle rvision 90. Autres considrations 91. Convertir un projet interne en LLO? Une dcision importante Avantages Attirer de nouveaux usagers et surtout contributeurs pour une croissance accrue du logiciel (cooprer avec d'autres experts travers le monde au lieu de comptitionner avec eux) Bnficier du retour de la communaut (nouvelles fonctionnalits, bug fix, tests, docs, etc.) Augmenter la viabilit long terme du logiciel (bus number, survie au dpart du crateur original) Dsavantages Perte de contrle partielle du crateur original sur le projet (le comit de direction prend le contrle) Perte potentielle d'un avantage comptitif? 92. Convertir un projet interne en LLO? Une dcision importante Questions importantes A-t-on la capacit d'attirer une communaut suffisamment grande pour gnrer un retour significatif? Comment financer nos activits de support du projet LLO? Est-on prts jouer le jeu et accepter la perte de contrle partielle sur la vision et direction du projet? Est-on prts travailler en mode distribu (pourrait demander une adaptation si l'quipe tait 100% locale auparavant) Choix de licence stratgique Rciproque (GPL, etc.): assure que le code demeure libre mais risque de faire reculer certains utilisateurs / contributeurs potentiels (ex: revendeurs de produit valeur ajoute) Non-rciproque (MIT, BSD, Apache) moins contraignant, plus propice l'usage commercial ou par des revendeurs propritaires 93. Autres considrations Possibilit d'un Fork Gestion par comit vs benevolent dictator Rvisions de scurit Fournisseurs de services ($) Support technique professionnel Formation Dveloppement de fonctionnalits 94. Incubateur de LLO 95. Incubateur Voir incubateur OSGeo: http://www.osgeo.org/incubator/ Objectif: Vrifier l'intgrit et la viabilit long terme d'un projet LLO avant son admission dans la fondation Rgles d'admission dans l'incubateur Formulaire d'application Mentor Licence ouverte approuve par l'OSI Potentiel de graduation Rgles de graduation de l'incubateur (voir checklist) Aspect lgal Communaut active et quilibre Gestion ouverte et Dveloppement ouvert 96. Incubateur Critres de graduation (Checklist) (1/3) Aspect lgal: Licence ouverte approuve par l'OSI (opensource.org) Validation de la provenance du code source Ententes de contribution, signe par tous les committeurs Communaut active et quilibre Communaut active et quilibre d'usagers et contributeurs (subjectif, signe de viabilit long terme) Mcanismes de communication ouverts en utilisation (site Web, listes, forums) 97. Incubateur Critres de graduation (Checklist) (2/3) Gestion ouverte Mcanisme de gestion et de dcision ouverts et documents Comit de direction Statut de comitteur Mcanisme ouvert d'ajout de membres au comit de direction et committeurs 98. Incubateur Critres de graduation (Checklist) (3/3) Dveloppement ouvert Mthodes de dveloppement ouvertes et documentes Infrastructure LLO minimale (Dpot code source, site Web, bug tracker, liste discussion) Gestion des changements (RFC) Processus de rvision Convention de codage / committer guidelines 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 rgles de graduation lorsque ncessaire Rgles d'oprations du comit simiaires au comit de direction d'un projet LLO Les membres du comit sont des anciens mentors ou mentors potentiels (exprience requise) 100. Comit d'incubation (ex: OSGeo) (2/3) Processus d'incubation type: Un projet applique auprs 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 ncessaires pour rencontrer tous les critres 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 progrs (wiki) Lorsque le mentor juge que le projet a rempli tous les critres, il soumet une motion au comit incubation pour proposer la graduation du projet 101. Comit d'incubation (ex: OSGeo) (3/3) Processus d'incubation type (suite): Les membres du comit incubation ont une semaine pour rviser le rapport de progrs Des ajustements sont habituellements proposs pendant la priode d'valuation Une fois tous les commentaires adresss, le comit passe au vote Si le vote est positif, le projet est gradut. Une recommandation d'admission officielle est transmise au CA (board) de la fondation Si le vote est ngatif, alors le projet doit faire les correctifs ncessaires et revenir pour une nouvelle demande de graduation plus tard 102. Liens utiles 103. Liens utiles Producing Open Source Software http://producingoss.com/ How to maintain a successful open source project https://medium.com/p/aaa2a5437d3a Rgles d'opration du comit de direction MapServer (RFC 23): http://mapserver.org/development/rfc/ms-rfc-23.html Rgles d'engagement des committeurs MapServer (RFC 7.1): http://mapserver.org/development/rfc/ms-rfc-7.1.html Processus de gestion de rvisions 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