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

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

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

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

“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

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

Logiciel libre et ouvert
Licence
Programme
Code Source
Documentation
d'utilisation

Logiciel propriétaire
Licence
Programme
EXE
Documentation
d'utilisation

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

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 LGPL
MIT/X
BSD
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

Communauté
(à la fois
conepteur,
gestionnaire
et utilisateur)

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

Contributeurs
ré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
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

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

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

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/

“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é directeur
● Comité technique
● Statut de “committeur”
● Contributeurs
● Gestion des changement (RFC)
● Gestion des révisions

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

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)

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

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)

● 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
● Conventions et politiques de travail du projet
● Vision générale du produit (feuille de route)
● Gestion des droits d'accès aux services

● 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

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é

Statut de “committeur” (1/4)
● Privilège:
● Permission de contribuer au dépôt de code source
directement
● 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)

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

● 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

● 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

Règles d'engagement du “committeur”

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

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

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

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

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.

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

Gestion des révisions
● Exemple de MapServer, voir RFC-34
● 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

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/

Branchement du code source
● Multiples stratégies possibles
● Exemple:
http://www.liquibase.org/development/branches.html

Exemples d'application des processus

Mise en place
d'un comité technique

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

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

Mise en place
● 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

Mise en place
● 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

Mise en place
● 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

Mise en place
● 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

Mise en place
● 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é

Mise en place
● 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 le 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

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

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)

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

(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

(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

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

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

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

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

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

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