atelier développement et gestion de logiciel libre et ...€¦ · daniel morissette président,...

Atelier

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

25 juillet 2013

Daniel [email protected]

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

Fondations LLO

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

Introduction

“Libre” ou “Open Source”?

● L'“Open Source” est une méthodologie de développement (motivations pratiques)

● Le “Libre” est un mouvementsocial (motivations éthiques)

● Les motivations diffèrent mais les deux groupes se rejoignent sur la solution

Qu'est-ce qu'un logiciel?

Logiciel

* Image courtoisie de “Master isolated images” / FreeDigitalPhotos.net

Logiciel libre et ouvert

Licence

ProgrammeCode Source

Documentation

d'utilisation

Logiciel propriétaire

Licence

ProgrammeEXE

Documentation

d'utilisation

11

Les licences

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

Catégories de licences

Shareware Propriétaire

Utiliser

Copier

Étudier

Modifier

Libre ouOpen Source

FreewareGratuit

Limite temporelle ou fonctionnelle

Limiteselon licence d'utilisation

sauf copie de sauvegarde

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

Licences

GPL LGPLMIT/XBSD

Réciproque(copyleft)

Non-réciproque

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

Modèle de fonctionnement

Éditeur propriétaire vs Projet LLO

Modèle de l'éditeur propriétaire

* Image courtoisie supercoloring.com

$ $ $$ $ $ $ $ $

Direction

R&D Marketing RH ...

Prod. Mgr, devs, docs, QA, etc

$ $ $$ $ $ $ $ $

Modèle du projet LLO(Mythe)

Image: Paul Ramsey, Beyond Nerds Bearing Gifts, The future of the Open Source Economy

Modèle du projet LLOCommunauté

(à la fois conepteur, gestionnaireet utilisateur)

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

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.)


Contributeursréguliers

“Power users”

Comité de direction

Committeurs


● 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.

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)

Infrastructure technique d'un projet LLO

Licence

ProgrammeCode Source

Documentation

d'utilisation

Infrastructure technique LLO

SiteWeb

“Packaging”

Dépotde codesource

ListeForums

IRC

Wiki

Suitede

tests

“Bug tracker”

Intégrationcontinue

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

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 chancede 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

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”

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

“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

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

https://github.com/mapserver/coverage

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/

https://travis-ci.org/tbonfort/mapserver/

“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.)

Processus de gestion d'un projet LLO

Processus de gestion LLO

● Gouvernance

● Mécanisme de décision

● Comité de direction

● Statut de “committeur”

● Gestion des changement (RFC)

● Gestion des révisions

● Processus/cycle de publication de révisions

● Branchement du code source

● Entente de contribution (“Contributor Agreement”)

● Convention de codage / “Committer Guidelines”

Mécanismes de décision

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.html#detailed-process

http://mapserver.org/development/rfc/ms-rfc-23.html#detailed-process

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

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)


● Autorité ultime du projet

● Gestion de tous les aspects du projet

● Processus de décision (consensus + vote)

● Provenance des membres variée et équilibrée

● Usagers vs contributeurs

● É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)

● Président (“chair”) élu parmi les membres du comité

● Voir MapServer RFC 23:

● http://mapserver.org/development/rfc/ms-rfc-23.html

http://mapserver.org/development/rfc/ms-rfc-23.html


● Responsabilités:● Conventions et politiques de travail du projet

● Vision générale du produit (“roadmap”)● Coordonner la publication de révisions régulières du logiciel

● Réviser et approuver les demandes de changement (RFC)

● Gestion de l'infrastructure du projet (git/svn, site web, etc)

● Relation avec la fondation OSGeo

● Définir les priorités du projet

● Création et supervision de sous-comités au besoin

● Etc.


● É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 plus de 2 mois (aucune

participation aux votes, réunions et autres activités du comité) peut être remplacé par vote des autres membres du comité

Statut de “Committeur”

Statut de “committeur”

● Privilège:● Permission de contribuer au dépôt de code source

directement

● Responsabilités:● s'assurer de l'intégrité des contributions (provenance,

propriété intellectuelle, brevets, licence, etc.)● supporter ses contributions de façon raisonnable (bugs,

etc.)● respecter les règles d'engagement (RFC 7.1)● signer et respecter l'entente de contribution


● Le comité de direction du projet, en tant qu'autorité ultime, 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”


● 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é de direction du projet qui passera au vote afin de vous attribuer le titre de committeur

● 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

Gestion des changements (RFC)

Gestion des changements

● Processus de RFC:● Discussions préliminaires sur la liste -dev● Production d'un document RFC (qui, quand,

quoi, pourquoi, comment, incompatibilités, etc)● Discussion du RFC● Vote du comité de direction● Implémentation, documentation, etc.

● Liste des RFCs disponible sur le site Web

Gestion des révisions


● Exemple de MapServer, voir RFC-34● http://mapserver.org/development/rfc/ms-rfc-34.html● Dépot d'un “Release plan”● Rôle de “release manager”● Cycle de révisions

– Cycle de +/- 6 mois entre les révisions– Dév. -> Rel. Plan -> Feature freeze -> betas -> RC ->

release



● 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/

http://semver.org/

Branchement du code source

● Multiples stratégies possibles● Exemple:

http://www.liquibase.org/development/branches.html

http://www.liquibase.org/development/branches.html

Règles d'engagement du “committeur”

Entente de contribution

● 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

● 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

http://wiki.osgeo.org/wiki/Contributor_Agreement

Convention de codage et “Committer guidelines”

● Visent l'uniformité du code et des méthodes de travail

● À respecter par le “committeur”● Voir MapServer RFC 7.1

● http://mapserver.org/development/rfc/ms-rfc-7.1.html

http://mapserver.org/development/rfc/ms-rfc-7.1.html

Exemples d'application des processus

Mise en placed'un comité de direction

Mise en place d'un comité de direction

● 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 ● 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


● 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


● 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


● 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


● 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


● 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é


● 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

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


● 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)


● 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

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é


● “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


● “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


● 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

el bon


● 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

Autres considérations

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?

●

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

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

Incubateur de LLO

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

● Développement ouvert

http://www.osgeo.org/incubator/

Incubateur – Critères de graduation(“Checklist”)

● 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)

● 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

● 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”

Comité d'incubation (ex: OSGeo)

● 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)

Comité d'incubation (ex: OSGeo)

● 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

● 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

Liens utiles

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):


● 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)


● 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

http://producingoss.com/

https://medium.com/p/aaa2a5437d3a


http://mapserver.org/development/rfc/ms-rfc-7.1.html


http://semver.org/

http://wiki.osgeo.org/wiki/Contributor_Agreement

http://www.osgeo.org/incubator/

http://www.osgeo.org/incubator/process/project_graduation_checklist.html

atelier développement et gestion de logiciel libre et ...€¦ · daniel morissette président,...

Documents